From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Akira Yokosawa <akiyks@gmail.com>
Subject: Re: [PATCH 2/7] docs: kdoc: micro-optimize KernRe
Date: Fri, 4 Jul 2025 00:27:12 +0200 [thread overview]
Message-ID: <20250704002712.05933173@foz.lan> (raw)
In-Reply-To: <878ql5kuou.fsf@trenco.lwn.net>
Em Thu, 03 Jul 2025 12:14:57 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:
> Mauro Carvalho Chehab <mchehab+huawei@kernel.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.
Maybe it is just some noise. When I ran the test, I executed the script
a couple of times just to ensure that disk cache won't be affecting it
too much.
The advantage of running just kerneldoc without Sphinx is that we
avoid doctree cache and other things that would add too much
randomness at the build time.
> 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.
I'm fine with .get().
Thanks,
Mauro
next prev parent reply other threads:[~2025-07-03 22:27 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-01 20:57 [PATCH 0/7] Further kernel-doc tweakery Jonathan Corbet
2025-07-01 20:57 ` [PATCH 1/7] docs: kdoc: don't reinvent string.strip() Jonathan Corbet
2025-07-03 15:43 ` Mauro Carvalho Chehab
2025-07-01 20:57 ` [PATCH 2/7] docs: kdoc: micro-optimize KernRe Jonathan Corbet
2025-07-03 15:38 ` Mauro Carvalho Chehab
2025-07-03 18:14 ` Jonathan Corbet
2025-07-03 22:27 ` Mauro Carvalho Chehab [this message]
2025-07-01 20:57 ` [PATCH 3/7] docs: kdoc: remove the brcount floor in process_proto_type() Jonathan Corbet
2025-07-03 15:39 ` Mauro Carvalho Chehab
2025-07-01 20:57 ` [PATCH 4/7] docs: kdoc: rework type prototype parsing Jonathan Corbet
2025-07-03 15:46 ` Mauro Carvalho Chehab
2025-07-01 20:57 ` [PATCH 5/7] docs: kdoc: some tweaks to process_proto_function() Jonathan Corbet
2025-07-03 15:48 ` Mauro Carvalho Chehab
2025-07-01 20:57 ` [PATCH 6/7] docs: kdoc: Remove a Python 2 comment Jonathan Corbet
2025-07-02 8:23 ` Jani Nikula
2025-07-03 15:49 ` Mauro Carvalho Chehab
2025-07-01 20:57 ` [PATCH 7/7] docs: kdoc: pretty up dump_enum() Jonathan Corbet
2025-07-03 15:57 ` Mauro Carvalho Chehab
2025-07-03 18:17 ` Jonathan Corbet
2025-07-03 22:29 ` Mauro Carvalho Chehab
2025-07-03 15:01 ` [PATCH 0/7] Further kernel-doc tweakery Akira Yokosawa
2025-07-03 18:20 ` Jonathan Corbet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250704002712.05933173@foz.lan \
--to=mchehab+huawei@kernel.org \
--cc=akiyks@gmail.com \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.