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

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

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