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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 30 Jun 2021 00:21:42 +0200
> From: Ergus <spacibba@aol.com>
> Cc: 49264@debbugs.gnu.org
> 
> >AFAICT, most of the time is taken by 'apply', but the profile doesn't
> >show which function is called by 'apply'.  Can you tell which function
> >is that?
> >
> apply is called in vc-responsible-backend and looking at the percentages
> it is obvious that the times are going in
> 
>    23%                      + vc-svn-responsible-p
>    18%                      + vc-bzr-responsible-p
>    15%                      + vc-hg-responsible-p
>     6%                      + vc-git-responsible-p
>     2%                      + vc-cvs-responsible-p
>     2%                      + vc-rcs-responsible-p
>     1%                      + vc-sccs-responsible-p
>     1%                      + vc-src-responsible-p
> ------
>    68%
> 
> These are the backends' functions that are passed to vc-call-backend in
> the mapcar in vc-responsible-backend and the output of
> vc-find-backend-function.

But if you still need to wait for dozens of seconds with just 2
backends, which take only 20% of the time according to the above, then
how do you want to speed this up in your case?  How about not using
ivy (which AFAICT is the root cause of this slowness)?

> >... after removing the "unused" VC back-ends, you say that the code
> >still runs very slowly.  So is the issue with VC back-ends still
> >relevant, and if so, how?
> >
> Yes, it is. It is still slow, lets say around 20-40 seconds to complete
> the command. But that's that's much faster than before (3-5 minutes);
> but still too slow to make the command usable.

It's still unacceptably slow, so that couldn't be a solution,
certainly not a general one, IMO.

> As a note here, when N files are in the same directory the normal thing
> is that all of them share the VCS. So calling a check function for all
> of them is redundant and slow.

AFAIR, that's not really true, and ISTR project.el aims to support the
use cases with several different VC backends.

And again, waiting for 30 seconds when you have just 10 buffers is
unacceptable.  E.g., in the session where I'm writing this, I have 80
buffers that visit files in a single branch of the Emacs Git
repository, almost an order of magnitude more than your 10 buffers.

So we must find some better way of getting reasonable performance in
this use case.  If the round-trip of the VC backend to a remote
filesystem is the bottleneck, let's try to speed that up in some way.