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: Philip Kaludercic <philipk <at> posteo.net>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 58950 <at> debbugs.gnu.org
Subject: bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance
Date: Sat, 31 Dec 2022 13:56:15 +0000

Dmitry Gutov <dgutov <at> 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.

Previous Next

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