[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance
From: |
Philip Kaludercic |
Subject: |
bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance |
Date: |
Sat, 31 Dec 2022 13:56:15 +0000 |
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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance,
Philip Kaludercic <=