GNU bug report logs - #49264
28.0.50; project.el+tramp performance issue

Previous Next

Package: emacs;

Reported by: Ergus <spacibba <at> aol.com>

Date: Mon, 28 Jun 2021 22:12:02 UTC

Severity: normal

Found in version 28.0.50

Done: Dmitry Gutov <dgutov <at> yandex.ru>

Bug is archived. No further changes may be made.

Full log


Message #11 received at 49264 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Ergus <spacibba <at> aol.com>, 49264 <at> debbugs.gnu.org
Subject: Re: bug#49264: 28.0.50; project.el+tramp performance issue
Date: Tue, 29 Jun 2021 16:00:02 +0300
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.




This bug report was last modified 3 years and 274 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.