bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dmitry Gutov
Subject: bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance
Date: Thu, 5 Jan 2023 02:00:12 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

On 31/12/2022 15:56, Philip Kaludercic wrote:
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.

It does look too ambitious for the release branch.

On the merits of the change itself, maybe Mattias or Stefan have some thoughts?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]