GNU bug report logs - #58950
[PATCH] * lisp/subr.el (buffer-match-p): Optimise performance

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Philip Kaludercic <philipk <at> posteo.net>, 58950 <at> debbugs.gnu.org
Subject: bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance
Date: Mon, 7 Nov 2022 03:04:35 +0200

On 01.11.2022 21:11, Philip Kaludercic wrote:
> 1. Style.  I wrap the defun in a let (or rather letrec) block to avoid
>     littering the global namespace.  It isn't necessary, and one could
>     argue it makes debugging more difficult.
> 
> 2. Caching policy.  Caching is critical to this optimisation.  Just
>     using byte-compilation would cause the above test to slow down to
>     (76.323692627 656 57.088315405).  The question is if the hash map
>     will collect too much garbage over time, and if there is a better
>     approach that could be taken?

I'd like to let our language-level specialists to take the deeper look.

This approach looks the most straightforward, but there could be others, 
just like "compiling" the form inside defcustom setter (for 
project-kill-buffer-conditions, and every similar option), doing 
precompilation closer to where the rules are used (similar to 
font-lock-compile-keywords), or not doing any of that. All depending on 
how long a typical compilation takes, and how many buffers the user has 
to have, to see any noticeable benefit.

On the last note, I'm curious how many buffers would it take to see a 
50ms improvement in match-buffers' runtime when using the current 
project-kill-buffer-conditions's value, for example.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.