From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#49264: 28.0.50; project.el+tramp performance issue Date: Wed, 30 Jun 2021 15:46:26 +0300 Message-ID: <83sg0zmsf1.fsf@gnu.org> References: <87fsx13aiz.fsf.ref@aol.com> <87fsx13aiz.fsf@aol.com> <83mtr8ooz4.fsf@gnu.org> <20210629222142.jbyegdo72wkp6vv2@Ergus> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11973"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 49264@debbugs.gnu.org To: Ergus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jun 30 14:47:25 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lyZci-0002rL-A7 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 30 Jun 2021 14:47:24 +0200 Original-Received: from localhost ([::1]:52372 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lyZch-00007J-8s for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 30 Jun 2021 08:47:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50300) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lyZcM-0008Sa-U4 for bug-gnu-emacs@gnu.org; Wed, 30 Jun 2021 08:47:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45165) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lyZcM-0001qe-J6 for bug-gnu-emacs@gnu.org; Wed, 30 Jun 2021 08:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lyZcM-0000Z8-Hh for bug-gnu-emacs@gnu.org; Wed, 30 Jun 2021 08:47:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Jun 2021 12:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49264 X-GNU-PR-Package: emacs Original-Received: via spool by 49264-submit@debbugs.gnu.org id=B49264.16250571932135 (code B ref 49264); Wed, 30 Jun 2021 12:47:02 +0000 Original-Received: (at 49264) by debbugs.gnu.org; 30 Jun 2021 12:46:33 +0000 Original-Received: from localhost ([127.0.0.1]:56711 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyZbs-0000YM-MN for submit@debbugs.gnu.org; Wed, 30 Jun 2021 08:46:32 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:52442) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyZbr-0000YB-JO for 49264@debbugs.gnu.org; Wed, 30 Jun 2021 08:46:31 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36904) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lyZbm-0001Ty-B4; Wed, 30 Jun 2021 08:46:26 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4872 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lyZbl-0003th-V4; Wed, 30 Jun 2021 08:46:26 -0400 In-Reply-To: <20210629222142.jbyegdo72wkp6vv2@Ergus> (message from Ergus on Wed, 30 Jun 2021 00:21:42 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:209166 Archived-At: > Date: Wed, 30 Jun 2021 00:21:42 +0200 > From: Ergus > 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.