bug#59935: 29.0.60; project-list-buffers is slow

[Eli Zaretskii]

> Cc: juri@linkov.net
> Date: Sat, 10 Dec 2022 03:49:47 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> When you invoke 'C-x p C-b', there's a noticeable pause before the
> buffer list is displayed. It's ~400ms over here when there are 46
> non-hidden buffers in the running session.
> 
> What I think is happening, the predicate is called 46, which in turn 
> calls (project-buffers pr) 46 times, and that ends up being 46 times 
> slower than one might have anticipated.
> 
> Not sure what's the best fix here (especially in time for the release),
> but if the FILTER-PREDICATE arg to list-buffers-noselect turned into a
> factory function (e.g. FILTER-PREDICATE-MAKER), that would be one
> solution.
> 
> Another would be to only leave the legacy codepath: it's not affected,
> project-buffers is only called once there.
> 
> Curiously, though, it shows a different list of buffers. It also
> includes "hidden" buffers - diff-syntax, Echo Area, etc. We should look
> into that either way.

I'm not following.  Are you saying that the problem is that the
FILTER-PREDICATE argument to list-buffers-noselect calls
project-buffers for each buffer?  If so, I don't understand why a
trivial change to project-list-buffers could not call project-buffers
just once, and then reuse the value in the call to
list-buffers-noselect both as the BUFFER-LIST argument and (if needed)
in the FILTER-PREDICATE argument, using memq.

If this is not the problem, then what is?

> And the patch is this:

Consequently, I don't understand the rationale for this patch, nor for
the combined one you posted later.  Please elaborate.

P.S. Btw, if you are not sure the multiple calls to project-buffers is
the reason for the slow operation, how about profiling it to be sure?
We may be barking up the wrong tree.