linux-kernel - Re: [PATCH 2/7] docs: kdoc: micro-optimize KernRe

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <878ql5kuou.fsf@trenco.lwn.net>
Date: Thu, 03 Jul 2025 12:14:57 -0600
From: Jonathan Corbet <corbet@....net>
To: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
Cc: linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, Akira Yokosawa
 <akiyks@...il.com>
Subject: Re: [PATCH 2/7] docs: kdoc: micro-optimize KernRe

Mauro Carvalho Chehab <mchehab+huawei@...nel.org> writes:

> Hmm... I opted for this particular way of checking is that I
> expect that check inside a hash at dict would be faster than
> letting it crash then raise an exception. 

Raising an exception is not quite a "crash" and, if the caching is doing
any good, it should be ... exceptional.  That pattern is often shown as
a better way to do conditional dict lookups, so I've tended to follow
it, even though I'm not a big fan of exceptions in general.

> Btw, one easy way to check how much it affects performance
> (if any) would be to run it in "rogue" mode with:
>
> 	$ time ./scripts/kernel-doc.py -N .
>
> This will run kernel-doc.py for all files at the entire Kernel
> tree, only reporting problems. If you want to do changes like
> this that might introduce performance regressions, I suggest
> running it once, just to fill disk caches, and then run it
> again before/after such changes.
>
> Anyway, I did such measurements before/after your patch.
> the difference was not relevant: just one second of difference:
>
> original code:
>
> real	1m20,839s
> user	1m19,594s
> sys	0m0,998s
>
> after your change:
>
> real	1m21,805s
> user	1m20,612s
> sys	0m0,929s
>
> I don't mind myself to be one second slower, but this is hardly
> a micro-optimization ;-)

Docs builds generally went slightly faster for me, but that is always a
noisy signal.

Anyway, I am not tied to this patch and can drop it.  Or I suppose I
could just redo it with .get(), which avoids both the double lookup and
the exception.

Thanks,

jon