bug#49264: 28.0.50; project.el+tramp performance issue

[Dmitry Gutov <dgutov@yandex.ru>]

Hi!

Thanks for the report, I'll follow up on this discussion some more 
later, but some initial observations:

On 29.06.2021 01:11, Ergus via Bug reports for GNU Emacs, the Swiss army 
knife of text editors wrote:
> As a workaround I removed all the uninteresting handlers from
> vc-handled-backends and I get better times now, but IMHO it is still
> very inefficient (almost a minute for project-switch-to-buffer is
> excessive). And make it practically unusable.

Could you evaluate (benchmark 1 '(project-current)) in one of your 
buffers? That should give us an estimate how long it takes to find the 
"current project" on your remote system.

If I'm right, project-switch-to-buffer should take 25 x (that time).

If you indeed only have 25 buffers (including hidden ones).

> In any case:
> 
> Maybe (I think I mentioned this before) `project.el` needs a sort of
> cache to speedup some functions like `project-current` that are called
> very frequently inside the project.el code.

The difficulty here is probably with the large latency to the remote 
system. And our current approach calls the "find current project" logic 
for each open buffer.

Even if we add the "current project" cache, it will only take effect at 
second and further invocations. Your first project-switch-to-buffer call 
will still take 3-5 minutes, which is unacceptable.

Please get back to us with the requested measurements, and perhaps other 
observations (any research initiative is welcome), but if finding the 
current vc root for each buffer is unavoidably slow, we'll finally need 
to switch to a "project-contains-buffer-p generic" approach, previously 
discussed in e.g. "Speed up project-kill-buffers" thread on emacs-devel.