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

[Philip Kaludercic <philipk@posteo.net>]

Dmitry Gutov <dgutov@yandex.ru> writes:

> 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.

Ping?  If this change is too controversial, I'd like to backport the
changes from bug#58951 and apply them since they are fixing an actual bug.