Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> 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
