[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance
From: |
Stefan Monnier |
Subject: |
bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance |
Date: |
Wed, 04 Jan 2023 23:31:26 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
>>>> 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?
You could make the hash table key-weak (since the test is `eq` it will
have no detrimental effect and will avoid most risks of leaks).
>>> I'd like to let our language-level specialists to take the deeper look.
Do we have any reason to believe that the performance of
`buffer-match-p` is a problem in `display-buffer-alist`?
The benchmark you quote seems to be fairly different from what
`display-buffer` does. I'm not surprised your optimization improves
this benchmark, but I'm wondering whether this use-case corresponds to
a real life situation (and if so which).
>>> 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.
Also, where is `match-buffers` used? I only see it used in
`lisp/net/rcirc.el` in a way that can trivially be replaced with
something much more efficient.
To be clear: I don't much like the kind of mini-language we invented for
`buffer-match-p`. I'd prefer we just used plain old ELisp for that.
It's a bit more verbose for that particular application, but:
- we have a much more efficient interpreter at hand.
- it's useful for many more things, so it's much wore valuable to
learn it.
- it's a lot more powerful/general.
Stefan
- bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance, Dmitry Gutov, 2023/01/04
- bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance,
Stefan Monnier <=
- bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance, Mattias Engdegård, 2023/01/05
- bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance, Dmitry Gutov, 2023/01/05
- bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance, Mattias Engdegård, 2023/01/06
- bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance, Dmitry Gutov, 2023/01/06
- bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance, Mattias Engdegård, 2023/01/07
- bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance, Dmitry Gutov, 2023/01/08
- bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance, Stefan Monnier, 2023/01/09
bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance, Dmitry Gutov, 2023/01/05