From unknown Sat Jun 21 03:29:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#49264: 28.0.50; project.el+tramp performance issue Resent-From: Ergus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 28 Jun 2021 22:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 49264 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 49264@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.16249182927997 (code B ref -1); Mon, 28 Jun 2021 22:12:02 +0000 Received: (at submit) by debbugs.gnu.org; 28 Jun 2021 22:11:32 +0000 Received: from localhost ([127.0.0.1]:53227 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lxzTX-00024u-8G for submit@debbugs.gnu.org; Mon, 28 Jun 2021 18:11:31 -0400 Received: from lists.gnu.org ([209.51.188.17]:40232) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lxzTT-00024m-Op for submit@debbugs.gnu.org; Mon, 28 Jun 2021 18:11:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51574) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lxzTS-0007w9-1p for bug-gnu-emacs@gnu.org; Mon, 28 Jun 2021 18:11:27 -0400 Received: from sonic302-3.consmr.mail.bf2.yahoo.com ([74.6.135.42]:41670) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lxzTN-000887-HB for bug-gnu-emacs@gnu.org; Mon, 28 Jun 2021 18:11:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1624918279; bh=yXMBLpUkKtciNPAdYKF0xinWWVzc328j8BDTdQPc5Fg=; h=From:To:Cc:Subject:Date:References:From:Subject:Reply-To; b=fyj53isZtmkLBs/SBIJds6xb/TTHdfQlSJohVPmzIpxO1X+4jdKM29WXLpgRHC7y2t8ywvKXcyZ1O02vgJlkoTQVIhsQlmtsGC+KCg+Vg+3hkN/e1egPgJtGgStdmQuNnReSYq+Zvmh0yRVnrk8gj0HCnvrXMKunzumkGHyBq3n7yckfnbVFP3XuzyswpC0PBywSLSifYMGXbTkH5ILhvdCibwusZItX5bSrWj9NC83p9dh1Ogi8Ht+Z7zh6rAiQPTYf1sDZqaNrD3mqLtkD4HuMbdSawXVA/quG1Neb4c34kHCXXvNBIrcZHe4o4/6iNNTd6o0TFiAZed+eDQBEJA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624918279; bh=wH2frLZevEKxC6JMKP/jJVQ6D2KA+qNU9BTZIJDvhRw=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=IT2PycGsTWQvWFs4adtBuIonpY0nwKUkVWh9PFy9IC821DKe+iFb4f34ZsSFmTW6JNYT2xicLq+Xdi4kbZaw+hfAYGEZCexAvTFGfUEQcQma7wLwSP08D9AMhqcH+BEAbzRTEkNBKp6FhPUKMXUey/9aE5TPEeH2I80F9DXyZpBDJmnDDs6j7EtTDHmENXGAmlM5V+dZBzt4lqYR6NO9I+ViCn6/EJw435sUSJFXF0DvyJpgyhsm72Ex4VmtKTuNYbBKeeBB0R1zRsVHyIN7mqHck/43WAlnrW+KEeqaQq71AkkwFoJeIcvdZ9jj0tGCAKE9Mu0x44be3d+5h3VqbA== X-YMail-OSG: WN7SN1wVM1nzAbeJV7E9LtPCBrHIeQf1a_NwYHycAAr9lT1ZAUR.9E1zO8PmMY3 Jh.hpjMzdiJfWr7bQjkGK.3EC90wTcaknCiARy.3qwdVFW0GywARC9g3R6MjAw.w98evw_lu8aLU Ay9vLk6AdphvGMCx33dMl0c7XSKQ68nqIs3wqczQtLpxWFLSFJpwtM1lPZ_TL3Xn5sqKysdjkTJv rHSjG4rpTqlHjGhW5fnr7QfJN5H5NX_kPK9flWp16vucEHTQ2xEKn9xVdTtIZjzGl37UlzKzlJEF xelCSN.kfcwHUlADEi.e_6WiXZAOFDVi91fZE4vqSTJL1Iw7xVn3ubjGbXMxLRRzRqGlsZxh40Wa 3wudgkttiTF..w0ijj0Ymtx.n7XzfQVHeH2SbcoEvqyW9FkM2wiqiZyTtN_4n7O9EMU7IFBbvBtm ERpayLBrhESKraTf_Ag_5IW46gv6URVB5IKsfwYNxa2swoDsPa2hIcDX9h_Tpea4lhCL_Lae0TER 3kc.OU.bgb1mFmgDyAUc34Dp09P1B1i0ZD0l0fKJEfVZXq5S.PextjLfZowffriQNrW_NGWcE.mS KIFjzU15QbSSqKVL653T.oXidTtbUlnTB37H1w9jqZAz8tnxw7QNgR_NHvgg0JlvaCNAOsATBgjy 2PDQlmyLwU_8PB6EGozmihaHz3udwViNMNv9rXGj7SKyYM9X9OfJw0SM96LsvRpI7Y1hOOozX5UO EXH6A8xA8ip0oTLbetege0YM9e6YqugsniGoOnQz2fr2DUTeboyr3eyCECOyWqXgEQpRzDE18i84 PgmPnAbYSf37ZmpM4UgBfXKa.W8Q02Vh.ZSGYrJgw5TINRbc3QE030M2Od_3K4Of9x2n0X9V6AXc TzzPkmGangw0oKVwh5ghURJLfVkBu20wJ5VwjuxiXuzdceXgAd8_Dn_O1zTHfehe74r5jMch3Avd QY_ZppXU86hAWlQxWrGKAWkH5ynlcgjK2cUmYJH7ACeDQkkaMCxyWH3mJFo.Oe4.bGf2lCpHls0T IJk2ltKJscmfixKryDBsoo3dpucDeauuWKTY9wJ7odIy3i6hLvPw.BKm9Di3BHzO4HX6BVWobsnw tICzEAA0oAJInpLDB_Vz7xoxmKlnqYYXeyk6J51ea5KPNMQnHKmK5IPzdju8a0tfRDbjfGUIaaZn HgEkApx3UDNxEU9jDaA.uj.mrRD7XMc3ECQzXjplW9e6rN2i5H_uGCD4fsOeLJXGWDIS6VDGAwFG rRHtkgO.HVzeoQ_PWJxOXUlIFvUvQKstSUL7LSa8WLWazEnRWIxUeXut_ba1euqnuKpB5gwLpxsj yNQyhh9xvoA6gXbOclTr7gNXOKFSvwFSZNxHmJn7lWdqvQ1G7213sZf3oZwSX_cby45nkTXbbcz8 5FtRZZiQ8gRnQ0.j0.hlAVaKm7b_uA4z9IjXPcqUqlLk7qwn5g71vtjD4Okrpc3Zfl1tFMI7kNHO qGOQSjikZlj6GQ2Pr0MArHF5Ipxc43YOCRw5rmMOHzZYl0AytNlQzaE9vFiMZEUSsdmwYt0ihfN0 XLIsreaUwkHTxr41Fa1Lm1z1_Cjl7LLDJZpCWYRmnz2hycoY6UXOvuqtIeCB1Wyf482x1IewZrtR 4KDMY7kVqcAYouCGKEkYf_XutWCWuh1cgGROEtv6Uq0BrOIj_aA.KqIuhnWu033oPadz8WfgKElU CximrCC5u02A7Y5pIK3ahReDLaHBVQF3Mkkw06gxKdJKcksBtVyK7z1MBvhDkwMiDs8XVOuYSvdm Q4K9TQtAIRQQx.QxWxJQNq71IQkHf_jkK6b74YYoWCXlK8eKKIxbl3A0AKsaUY.t2PIxXvj7nkeH eFYRTyyNPyy3t7i5E6fOjj5qAV7_HJdplmcIPsfdsqTM26KVv8QBpY4M7MKhG.qpLvzk8CxwwnOw 7kkVlauDAU7rLUe7dqjL6K7HI1IWxHVt5sGq0uxDyCESlvOT6j40Jv8YQEPdM2yU0tKUrmz6hvRf gLxQRdV93.8J02IxwCEcy4ng2MjQrXKj.3YuXfi4hwXok3UfMXoL3XqL_d_hZHhcera3_WxMQiTK jUc44tKujJ9o2mMwYbOIPSmM9zKjFu8XCXUf.gvcc_IxVBhqgXk._Lu7k0MGJxTDLlqaqdL1TCR2 ZlgXrimw2hmTZ_FwC36E2mRdb3JW5si41_kdK5rSGH1NesMej3_toCETCSKkjEeD8LhSwUIVPaDQ EQXzPUzDmL6GrAmkBrCn4EBq60u4m3omlQ3DCVzRdlFJ4xZ1oHpSBuR8fK8znZwSTB_HU5Acsrzx JPH0oLQEb.t4XYi04wVsXBY_IMg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Mon, 28 Jun 2021 22:11:19 +0000 Received: by kubenode503.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e2ff5b4c72c268af2e9aa79d29da4757; Mon, 28 Jun 2021 22:11:17 +0000 (UTC) From: Ergus Date: Tue, 29 Jun 2021 00:11:00 +0200 Message-ID: <87fsx13aiz.fsf@aol.com> MIME-Version: 1.0 Content-Type: text/plain References: <87fsx13aiz.fsf.ref@aol.com> X-Mailer: WebService/1.1.18469 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Content-Length: 12506 Received-SPF: pass client-ip=74.6.135.42; envelope-from=spacibba@aol.com; helo=sonic302-3.consmr.mail.bf2.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Hi: Using tramp I tried to use project.el with a command like project-switch-to-buffer and it took like 10 minutes to complete. I ran a profiler and I found that most of the time was taken by an external function: global-tags-try-project-root project-current is called in a loop for all the opened buffers it calls project--find-in-directory that calls project-find-functions and there is going all the time. After some optimization in an external package; now the time is half than before but still very slow to use the command (around 3-5 minutes to complete) and running again the profiler I get this: 5637 89% - command-execute 5549 88% - byte-code 5549 88% - project--read-project-buffer 5549 88% - let* 5336 85% - read-buffer 5323 84% - ivy-completing-read 5323 84% - ivy-read 4941 78% - ivy--reset-state 4941 78% - ivy--buffer-list 4941 78% - internal-complete-buffer 4941 78% - # 4941 78% - and 4941 78% - equal 4941 78% - save-current-buffer 4941 78% - project-current 4941 78% - project--find-in-directory 4548 72% - project-try-vc 4537 72% - vc-responsible-backend 4478 71% - # 4478 71% - vc-call-backend 4478 71% - apply 1470 23% + vc-svn-responsible-p 1142 18% + vc-bzr-responsible-p 970 15% + vc-hg-responsible-p 390 6% + vc-git-responsible-p 156 2% + vc-cvs-responsible-p 126 2% + vc-rcs-responsible-p 108 1% + vc-sccs-responsible-p 98 1% + vc-src-responsible-p 57 0% + tramp-file-name-handler 11 0% + vc-file-getprop 393 6% + global-tags-try-project-root 375 5% + read-from-minibuffer 13 0% + if 213 3% + project-current 88 1% + funcall-interactively 572 9% + ... 51 0% + timer-event-handler 8 0% + redisplay_internal (C function) As you can see most of the time is still taken by project-current and I can't really understand why: 1) Are so many samples 4548 seems a very high number for only 25 opened buffers. 2) why project-try-vc still takes so much...? Specially for unfrequent vc systems in our days like svn or bzr that I am not using. 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. 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. Related with https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42966 VCS changing is not something that happens very often to require a check of all the backends everytime, several times for every buffer in many project.el functions right? Specially when using tramp. vc has vc-file-prop-obarray; maybe vc-responsible-backend should cache it's result there to avoid repeating time consuming computations? Either in the local system the performance penalty seems to be significant to me. Best, Ergus In GNU Emacs 28.0.50 (build 50, x86_64-pc-linux-gnu, GTK+ Version 3.24.29, cairo version 1.17.4) of 2021-06-26 built on Ergus Repository revision: b8f9e58ef72402e69a1f0960816184d52e5d2d29 Repository branch: master System Description: Arch Linux Configured using: 'configure --prefix=/home/ergo/.local/ --with-mailutils --with-json --with-x-toolkit=gtk3 --with-xft --with-wide-int --with-modules --with-cairo --with-harfbuzz --with-native-compilation' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: C++//law Minor modes in effect: global-git-commit-mode: t magit-auto-revert-mode: t diff-hl-margin-mode: t windmove-mode: t subword-mode: t hide-ifdef-mode: t preproc-font-lock-mode: t shell-dirtrack-mode: t show-paren-mode: t global-auto-revert-mode: t xclip-mode: t yas-global-mode: t yas-minor-mode: t electric-pair-mode: t flyspell-mode: t company-mode: t flycheck-mode: t counsel-mode: t ivy-mode: t composable-mark-mode: t composable-mode: t repeat-mode: t xterm-mouse-mode: t winner-mode: t save-place-mode: t which-key-mode: t override-global-mode: t delete-selection-mode: t savehist-mode: t global-display-fill-column-indicator-mode: t display-fill-column-indicator-mode: t global-display-line-numbers-mode: t display-line-numbers-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t size-indication-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t abbrev-mode: t Load-path shadows: /usr/share/emacs/site-lisp/cmake-mode hides /home/ergo/.emacs.d/elpa/cmake-mode-20210104.1831/cmake-mode /usr/share/emacs/site-lisp/notmuch-crypto hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-crypto /usr/share/emacs/site-lisp/notmuch-compat hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-compat /usr/share/emacs/site-lisp/notmuch-hello hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-hello /usr/share/emacs/site-lisp/notmuch hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch /usr/share/emacs/site-lisp/notmuch-show hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-show /usr/share/emacs/site-lisp/notmuch-maildir-fcc hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-maildir-fcc /usr/share/emacs/site-lisp/coolj hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/coolj /usr/share/emacs/site-lisp/notmuch-draft hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-draft /usr/share/emacs/site-lisp/notmuch-tree hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-tree /usr/share/emacs/site-lisp/notmuch-parser hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-parser /usr/share/emacs/site-lisp/notmuch-lib hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-lib /usr/share/emacs/site-lisp/notmuch-mua hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-mua /usr/share/emacs/site-lisp/notmuch-message hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-message /usr/share/emacs/site-lisp/notmuch-address hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-address /usr/share/emacs/site-lisp/notmuch-wash hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-wash /usr/share/emacs/site-lisp/notmuch-tag hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-tag /usr/share/emacs/site-lisp/notmuch-print hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-print /usr/share/emacs/site-lisp/notmuch-query hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-query /usr/share/emacs/site-lisp/notmuch-jump hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-jump /usr/share/emacs/site-lisp/notmuch-company hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-company /home/ergo/.emacs.d/elpa/transient-20210619.1100/transient hides /home/ergo/.local/share/emacs/28.0.50/lisp/transient Features: (shadow sort notmuch-company notmuch-lib notmuch-version notmuch-compat mm-view mml-smime smime dig mail-extr emacsbug sendmail magit-extras hi-lock magit-bookmark magit-submodule magit-obsolete magit-blame magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit magit-sequence magit-notes magit-worktree magit-tag magit-merge magit-branch magit-reset magit-files magit-refs magit-status magit package browse-url url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util mailcap url-handlers magit-repos magit-apply magit-wip magit-log which-func imenu magit-diff smerge-mode diff git-commit log-edit message rmc puny rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader add-log magit-core magit-autorevert magit-margin magit-transient magit-process with-editor server magit-mode transient magit-git magit-section magit-utils crm tramp-cmds global-tags ht generator async counsel-gtags pulse mc-separate-operations mc-edit-lines mc-hide-unmatched-lines-mode mc-mark-more mc-cycle-cursors multiple-cursors-core rect move-dup diff-hl-margin eieio-opt speedbar ezimage dframe shortdoc help-fns radix-tree vc-annotate amx s windmove misearch multi-isearch ffap url-parse url-vars face-remap vc-hg macrostep-c cmacexp macrostep cap-words superword subword hideif preproc-font-lock cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs dired-aux diff-hl-dired diff-hl log-view pcvs-util vc-dir ewoc vc tramp-cache tramp-sh tramp tramp-loaddefs trampver tramp-integration files-x tramp-compat shell pcomplete parse-time iso8601 time-date ls-lisp format-spec auth-source password-cache thingatpt vc-git diff-mode vc-dispatcher bookmark pp paren autorevert filenotify xclip yasnippet-snippets yasnippet elec-pair flyspell-correct-ivy flyspell-correct flyspell ispell company-keywords company-gtags company-dabbrev-code company-dabbrev company-files company-semantic company-template company-capf company flycheck json map find-func dash counsel xdg xref project dired-x dired dired-loaddefs compile text-property-search comint ansi-color swiper ivy-avy avy ivy flx ivy-faces ivy-overlay colir pcase term/tmux term/xterm xterm jka-compr init composable composable-mark powerline comp comp-cstr warnings subr-x powerline-separators color powerline-themes repeat xt-mouse simple-16-theme winner ring saveplace diminish edmacro kmacro which-key advice configmail cl-extra help-mode use-package use-package-ensure use-package-delight use-package-diminish use-package-bind-key bind-key use-package-core disp-table delsel savehist easy-mmode display-fill-column-indicator display-line-numbers info ede/auto eieio-base cl-seq seq eieio byte-opt bytecomp byte-compile cconv eieio-core cl-macs gv eieio-loaddefs cl-loaddefs cl-lib tex-site rx slime-autoloads early-init iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit x multi-tty make-network-process native-compile emacs) Memory information: ((conses 16 811583 75249) (symbols 48 30651 0) (strings 32 107218 13868) (string-bytes 1 4408538) (vectors 16 57480) (vector-slots 8 1324399 45245) (floats 8 342 1198) (intervals 56 53473 1428) (buffers 992 37)) From unknown Sat Jun 21 03:29:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#49264: 28.0.50; project.el+tramp performance issue Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Jun 2021 12:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49264 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ergus Cc: 49264@debbugs.gnu.org Received: via spool by 49264-submit@debbugs.gnu.org id=B49264.162496834312753 (code B ref 49264); Tue, 29 Jun 2021 12:06:02 +0000 Received: (at 49264) by debbugs.gnu.org; 29 Jun 2021 12:05:43 +0000 Received: from localhost ([127.0.0.1]:53786 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyCUo-0003Jd-Jf for submit@debbugs.gnu.org; Tue, 29 Jun 2021 08:05:42 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51698) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyCUn-0003JR-7Q for 49264@debbugs.gnu.org; Tue, 29 Jun 2021 08:05:41 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51772) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lyCUh-00058m-OQ; Tue, 29 Jun 2021 08:05:35 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1397 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 1lyCUh-00058G-A7; Tue, 29 Jun 2021 08:05:35 -0400 Date: Tue, 29 Jun 2021 15:05:35 +0300 Message-Id: <83mtr8ooz4.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87fsx13aiz.fsf@aol.com> (bug-gnu-emacs@gnu.org) References: <87fsx13aiz.fsf.ref@aol.com> <87fsx13aiz.fsf@aol.com> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 29 Jun 2021 00:11:00 +0200 > From: Ergus via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > Using tramp I tried to use project.el with a command like > project-switch-to-buffer and it took like 10 minutes to complete. > > I ran a profiler and I found that most of the time was taken by an > external function: global-tags-try-project-root That doesn't follow from the profile you show. According to the profile, global-tags-try-project-root takes just 6% of the CPU time. > project-current is called in a loop for all the opened buffers it calls > project--find-in-directory that calls project-find-functions and there > is going all the time. I don't see project-find-functions in the profile. Where is it and how does it come into this picture? > After some optimization in an external package; now the time is half > than before but still very slow to use the command (around 3-5 minutes > to complete) and running again the profiler I get this: > > 5637 89% - command-execute > 5549 88% - byte-code > 5549 88% - project--read-project-buffer > 5549 88% - let* > 5336 85% - read-buffer > 5323 84% - ivy-completing-read > 5323 84% - ivy-read > 4941 78% - ivy--reset-state > 4941 78% - ivy--buffer-list > 4941 78% - internal-complete-buffer > 4941 78% - # > 4941 78% - and > 4941 78% - equal > 4941 78% - save-current-buffer > 4941 78% - project-current > 4941 78% - project--find-in-directory > 4548 72% - project-try-vc > 4537 72% - vc-responsible-backend > 4478 71% - # > 4478 71% - vc-call-backend > 4478 71% - apply > 1470 23% + vc-svn-responsible-p > 1142 18% + vc-bzr-responsible-p > 970 15% + vc-hg-responsible-p > 390 6% + vc-git-responsible-p > 156 2% + vc-cvs-responsible-p > 126 2% + vc-rcs-responsible-p > 108 1% + vc-sccs-responsible-p > 98 1% + vc-src-responsible-p > 57 0% + tramp-file-name-handler > 11 0% + vc-file-getprop > 393 6% + global-tags-try-project-root > 375 5% + read-from-minibuffer > 13 0% + if > 213 3% + project-current > 88 1% + funcall-interactively > 572 9% + ... > 51 0% + timer-event-handler > 8 0% + redisplay_internal (C function) > > > As you can see most of the time is still taken by project-current and I > can't really understand why: 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? > 1) Are so many samples 4548 seems a very high number for only 25 opened > buffers. These two numbers are unrelated. 4548 is the number of time the profiler found the program counter inside project-try-vc and the functions it calls. This number has no relation to the number of buffers you have, it just means that code runs slowly. > 2) why project-try-vc still takes so much...? Specially for unfrequent > vc systems in our days like svn or bzr that I am not using. That was explained on emacs-devel. However, ... > 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. ... 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? More importantly, what is the profile after you remove the extra VC calls? > VCS changing is not something that happens very often to require a check > of all the backends everytime, several times for every buffer in many > project.el functions right? Specially when using tramp. Once again, given what you say above, this doesn't sound important, does it? The slow processing is elsewhere, and without seeing a profile with VC calls removed, it's hard to make progress in this matter, or give you some advice regarding potential reason(s). > vc has vc-file-prop-obarray; maybe vc-responsible-backend should cache > it's result there to avoid repeating time consuming computations? Again: is this issue relevant, given that without the VC calls the code is still very slow? From unknown Sat Jun 21 03:29:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#49264: 28.0.50; project.el+tramp performance issue Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Jun 2021 13:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49264 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ergus , 49264@debbugs.gnu.org Received: via spool by 49264-submit@debbugs.gnu.org id=B49264.162497161317826 (code B ref 49264); Tue, 29 Jun 2021 13:01:02 +0000 Received: (at 49264) by debbugs.gnu.org; 29 Jun 2021 13:00:13 +0000 Received: from localhost ([127.0.0.1]:53829 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyDLY-0004dS-RX for submit@debbugs.gnu.org; Tue, 29 Jun 2021 09:00:13 -0400 Received: from mail-wm1-f42.google.com ([209.85.128.42]:46872) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyDLX-0004cC-2f for 49264@debbugs.gnu.org; Tue, 29 Jun 2021 09:00:12 -0400 Received: by mail-wm1-f42.google.com with SMTP id v20-20020a05600c2154b02901dcefb16af0so2368514wml.5 for <49264@debbugs.gnu.org>; Tue, 29 Jun 2021 06:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=0CdbJzPJ/Ieg63bHkigcGJjzD9G5B4zTFFDqC0GaQYY=; b=TD7WGZk/f2VzWhHCsUmJdDjTqCPDCmNXL5zif4Ylwj8jfMrBxThh6wG/0tXoir7JgE JOrQ7cfEomXXEm3WHA0ALRno+qJhxxrQygiAPDczzQviSLazYaAlt9QBx4fO3cJWxqqf MEB6xdK5bauHZ0I961srVlQtwz4bWQKjnZhOjSQucU3FMg7lFt/FezwcyVViL1wV83Te Bbr3tkhC3vS0Q2GAiBzyvLVZtssZpTVCYZ7tzsZUWFPPGsxxNh1JZPS5ftFnQ2+eVUu5 9+9THjUZRHIfrpt9wEGxWRjp8jwpLlJ7/QAzxFLEJLSfSz/9BM0DFpMj8JIjaRj7iIhY kyRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0CdbJzPJ/Ieg63bHkigcGJjzD9G5B4zTFFDqC0GaQYY=; b=Nix555b79QwJ6OxwepyhnO6YdkyLbQThOvN/m8X3rSPBS4uS6eJHjA0TdvH4VBo4mR AdyDBuVOxVlOetWzuBXwynEuybp1E/FUZPklc7rCKwf4vV6y/37R5vMhlQZggcRl4syL 0knG6gwTtZOpsrv/nO50XWV93UOzIyBtGXTW4gXhLHvOuQ/iHH2AN5hOqsu1L5M77LqG GvtsA5k9jHA1+1aOVXpmpPgtQ8iJ/1FdgR3w0VVTyAM2/5/szTEra9wHwvVGsF5fOa7G BrHBj2dDC8pxm8C1aBduAToyIYy5lJvYsPCCz19Zzf0pZ0FFl+ZPGO8c/reqrDC1JKdb OFdg== X-Gm-Message-State: AOAM532BR/EDz2IrODuEJae38rPn6ZpIt48NdtdWTTgj1DiA1OsKbZdT QinjNeBiaJLqhT9P6Eoyikb7lZOKjck= X-Google-Smtp-Source: ABdhPJzxwv1AJ++K6loHriqg6/5bK5XCH7ss2AxhLjhGfC+ExJaUB7C9LbispZ71Mkrd7PS7Z6RBIg== X-Received: by 2002:a1c:7f4b:: with SMTP id a72mr5200048wmd.48.1624971605062; Tue, 29 Jun 2021 06:00:05 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id f62sm6426880wmf.22.2021.06.29.06.00.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Jun 2021 06:00:04 -0700 (PDT) References: <87fsx13aiz.fsf.ref@aol.com> <87fsx13aiz.fsf@aol.com> From: Dmitry Gutov Message-ID: <72c1b336-ae02-36c0-db40-f608bafecdf3@yandex.ru> Date: Tue, 29 Jun 2021 16:00:02 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <87fsx13aiz.fsf@aol.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) 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. From unknown Sat Jun 21 03:29:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#49264: 28.0.50; project.el+tramp performance issue Resent-From: Ergus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Jun 2021 22:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49264 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 49264@debbugs.gnu.org Received: via spool by 49264-submit@debbugs.gnu.org id=B49264.162500532415749 (code B ref 49264); Tue, 29 Jun 2021 22:23:01 +0000 Received: (at 49264) by debbugs.gnu.org; 29 Jun 2021 22:22:04 +0000 Received: from localhost ([127.0.0.1]:55872 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyM7H-00045x-D8 for submit@debbugs.gnu.org; Tue, 29 Jun 2021 18:22:03 -0400 Received: from sonic302-3.consmr.mail.bf2.yahoo.com ([74.6.135.42]:45451) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyM7G-00045T-DK for 49264@debbugs.gnu.org; Tue, 29 Jun 2021 18:22:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1625005316; bh=yzt3sAygmvlmvZYsmxoNHLcVJ9Fu7PIIfrhAMJeryH0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject:Reply-To; b=UY7ITrCueIzz8qg33W8vpBnNBwRr8N3Z/p8Qvs/y28gtWeQ/ZBNxsqKsQE2KSWS+9zfxmS97aJCfR8sy8lmARlnehpG3NmiiYJQubS4O96W+oUq6Yeih9JknTe3e90WDAf5sKOOVQ5KgAWnwHCDvpZHD8XV0DcvoQRgLbIAVuyRy9qX9xauJmEyl1rvphOAQA5SHyVuYvG2NSQgAorjdmFPFvWdj/H4X/r6Rfwlb3ivRt/lQchbQ49um6mWmGISGUenjL3LJ1ceaSMqO+1PcAgVnmw/mgU41Cx0cXG49Di7i7ul4iHBG2cYplruyyQCMo0yJYqjEQzqjtINpBuRdOQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625005316; bh=XpwTwltnenT/PdFMocFu4PJL8L8diMDe6nuxVqavA9X=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=ZOCjtfxKgmaBogHzJt63wiU1l3+T8ObHmw0MzOadQRi4e2Is2STQXynYba2BvLy2Ds/5crkeBydEaiq929ruzssCFsOa/A9omBAp5NkmlI5ku90AgEuuo0gQU/4uXDFL/wpnAHehsiCWO4ucrAeUrZxYzoSba56R8J772xnEdTvjlG1BeQNk6dsqW87DZ1uCyLyTY84BTJInFS3aIHw9Y8o5ipNCwAI8aw/nVNP9FCHmQZxZ3D/S66fUfMz/1ASorZ8NtTAOZAcBHF5vAd5z+7urSqsFUePrai/+7eqxb4NHVv6KebjnqiVwkcn+1OPhrsBivb+TWDIx6X43DRSw9g== X-YMail-OSG: vPZbcjoVM1m2.KE4s5Ig14Vg6CVVy3gVoxo2doiORuOBmke4_42uQLA7gL9fp3e Qg.2NJgZjNtTBsLVQsC0Lvr0a94GJ2o3mYMqQVplbbjiQeBKstMwDBYbKdCCt_mPzxSFqJrIpiJN LJm5BGyv6PD3Kl2tW8DbcI0I4CmI6n3FCVGnLGL7zBJ0MS19ZxlywvyG4Ph8TQhhpeFpepZhWeAp ZdtpN6F0CFwFVj9Gx0MrEWz8fBpummRBp7wK5gQaPcNBJ_nQKReSCbObn9l4LRyvXRAsWYw.uTDi hvIjFT8gHF3iHN5IRlT.oQ7Aj.IsDSLv0KeHqB3zLcgF2WBwwcJ96KvxuCBwfjZhptfBhaFTJaW9 DgKlF0qTv_cPb.aAb64Qw8MxzjNl9zgrR0qwTZ4dgg3AaCJNgv_HFUgpWFxz92lTY3qrREWETJ3J eruEWwxT61FGEU_T2lQUJLDTjFxh4EuGoQw3vwyeyx4niymNTmtaMMY7sSXaucZ5OaZV5lOt1Fy6 RGwsL99lONBc75Mbu4PEt6OAuGEgoEVzplUVDtuhad7En27Y5DrKA7iYTUqKomRLTez5.71nV0lM YKv8N6lp13Sa8XSR67NOslbcg2IuVrnkb4iRv.r68JVNy1WC0sFcjgs5WUx7t63gVjbMd.Y26ia6 6FNpmEtJmPDrT_WDQIMY3Os9T_I45dY6pAYE6MaDOtyh2jfYWOsFIGYS06TWFOkeVO.7.YFB0JTT 0tTRuCmButK3q1A.PLXzCbZ3jduTEdGoGNoclqe7OaNM067wiv3UL682zJ1E0FSJDrZUUKKX14_u Yl_OLffU.6CaYwOlef6CnRTaGCy7pILQ_yEtf8Nxp0w1OwMDpZtenJ3WWTQAdjQ8mwg79hsBmCDl 3E9xc4SFnDIgI5VdQzDRSKHsExthv8srGfHnNwPJP892rufO1OKoMREfSximpF3SRouOwY.0nTMD EaEvw.BII_LHLQq6hRqjyVpkH9hFFYyrExoOGzGxxNGrwrInO08NfSxaZgJcEGGUD6ZwjnrMG4qi E8ZymomtJ..kzrwCg7FP2xPTse3rBHs.SuhZgQez3b35DmBTacTf3YEf0Jk1y69i5.UeIE121BDI N6sLnk1nye9BEOifw9TYX3myAq_KILiNkggeD5F1cnviAJqhpFl_Ex.GVoKB7zbQFG__Xfs0nal3 3BQAllqod_fDVFMLGZ7mOC6xrIzK2lX8hypA9VV8caabzzfLPEzzmhTXKon.mLY0pqs073mVjcTa mcpcAgXbh9mQk0ydT2rOTBIK2P93RCU5Rrim2_1F.JUn_.v77sbuh2AYDZ7wm3j5jkE5ANTLBPhC RBRxeL85kpQkChsGzmNDMTimOM2TUzR_gxqInXrvykGchEpyPrYxgXt5rVhlej6YxYlZNtJQuj_1 dxNQUQMfFBn5x6RhgQ5qp6yWh7CGEynikBTrfXVU2I2jeOUggS_IXPZt5b9tHaC2ET8B2JtlmJYG 5Gg4PEwMlfSmpStXZF_61viZQLaay2nwPHnJiAoDQsARGGe97GqobFbCv6Hdujgh7zgarOfdco2C jABOhCY9aDaPCFHWBO3y07P3m2nWduKEPIlawYkC.Cr7BXZgl6406ovHo6QupEdziIQE8mjMI7lq fQOkftLz17IfpjTyzxaHeHcgohtOzhXu75FARyhNx8Kdhs1uLT8AlTJ_YPBFQzFdjlMJ3g3Kkdfa m1jP8X8prHNcpaeL67e1xjP9c0640h07d.5ZXkAayZE53m8AdO_teHZvgGlN4Dcw4EvACT.d10aP zrOOkDJm4NvUpE_IXVjlnWM5NpUoZlPdDHHk.YnIVC4R7QvMjoc51zf.5HS.jd.VKVI400rh_fuJ XaycWPGr4aQdIqNpEhH5FFVhSjR2KCQfLjrGGrkp6doEdR_4CFUJA9CUSGqwb1yCvmHT3OWCBIoV UwS5nIZ.GfY04ZWMQWW4k6LfUmu_bfmFNdJ2bNxYOMUaI.mTuTqEoroik8w9DZa3YB51KwsclX_7 a6L1miXXYSCSrP2xGH1K46HhtCq_OmQKjGhLy06bQ4YTm0UQ7PfV6mGZYFPZdFfR49zQ87fpNSeh tCXg2RnHR3xzxMAUc54EkNVUxDoyzHRUoPixleZLIRzwPv6QHwPmwX6lb9ihTW9Ju.6PYyVzynQj 64H5SDsQd9JDZpfZOuPvTHjOFlFZ7V1YKrgSu2UYdMQwHdEIlejyaRmqfP7T_PS7pCq6nBk6phBW SEEsBZRekTaA3gHFzUo6iXq8XOUahMr7uaNv2ZvrHyZXT98Ny.17OUpzSl0nirro.EhZGcjBOjft Oj3meNBAUwnR1KvDqeqIhHjLgXoMrVrAdZBYYZZVs_MyNdg8MwfJAZQAFlcOVauEaou.is28QO2p OXbZjrpV694xjIS0FiNHeMe0PsKxFIqH_2p8- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Tue, 29 Jun 2021 22:21:56 +0000 Received: by kubenode525.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 462f400b8bb535964166e44dab381a4a; Tue, 29 Jun 2021 22:21:52 +0000 (UTC) Date: Wed, 30 Jun 2021 00:21:42 +0200 From: Ergus Message-ID: <20210629222142.jbyegdo72wkp6vv2@Ergus> References: <87fsx13aiz.fsf.ref@aol.com> <87fsx13aiz.fsf@aol.com> <83mtr8ooz4.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <83mtr8ooz4.fsf@gnu.org> X-Mailer: WebService/1.1.18469 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Content-Length: 8614 X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi Eli: On Tue, Jun 29, 2021 at 03:05:35PM +0300, Eli Zaretskii wrote: >> Date: Tue, 29 Jun 2021 00:11:00 +0200 >> From: Ergus via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" >> >> Using tramp I tried to use project.el with a command like >> project-switch-to-buffer and it took like 10 minutes to complete. >> >> I ran a profiler and I found that most of the time was taken by an >> external function: global-tags-try-project-root > >That doesn't follow from the profile you show. According to the >profile, global-tags-try-project-root takes just 6% of the CPU time. > The profile is `After some optimization in an external package`. As explained 2 paragraphs next. Before the fix it was taking more or less the same percent than vc-responsible-backend. >> project-current is called in a loop for all the opened buffers it calls >> project--find-in-directory that calls project-find-functions and there >> is going all the time. > >I don't see project-find-functions in the profile. Where is it and >how does it come into this picture? project-find-functions is a hook called in project--find-in-directory (defun project--find-in-directory (dir) (run-hook-with-args-until-success 'project-find-functions dir)) > >> After some optimization in an external package; now the time is half >> than before but still very slow to use the command (around 3-5 minutes >> to complete) and running again the profiler I get this: >> >> 5637 89% - command-execute >> 5549 88% - byte-code >> 5549 88% - project--read-project-buffer >> 5549 88% - let* >> 5336 85% - read-buffer >> 5323 84% - ivy-completing-read >> 5323 84% - ivy-read >> 4941 78% - ivy--reset-state >> 4941 78% - ivy--buffer-list >> 4941 78% - internal-complete-buffer >> 4941 78% - # >> 4941 78% - and >> 4941 78% - equal >> 4941 78% - save-current-buffer >> 4941 78% - project-current >> 4941 78% - project--find-in-directory >> 4548 72% - project-try-vc >> 4537 72% - vc-responsible-backend >> 4478 71% - # >> 4478 71% - vc-call-backend >> 4478 71% - apply >> 1470 23% + vc-svn-responsible-p >> 1142 18% + vc-bzr-responsible-p >> 970 15% + vc-hg-responsible-p >> 390 6% + vc-git-responsible-p >> 156 2% + vc-cvs-responsible-p >> 126 2% + vc-rcs-responsible-p >> 108 1% + vc-sccs-responsible-p >> 98 1% + vc-src-responsible-p >> 57 0% + tramp-file-name-handler >> 11 0% + vc-file-getprop >> 393 6% + global-tags-try-project-root >> 375 5% + read-from-minibuffer >> 13 0% + if >> 213 3% + project-current >> 88 1% + funcall-interactively >> 572 9% + ... >> 51 0% + timer-event-handler >> 8 0% + redisplay_internal (C function) >> >> >> As you can see most of the time is still taken by project-current and I >> can't really understand why: > >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. >> 1) Are so many samples 4548 seems a very high number for only 25 opened >> buffers. > >These two numbers are unrelated. 4548 is the number of time the >profiler found the program counter inside project-try-vc and the >functions it calls. This number has no relation to the number of >buffers you have, it just means that code runs slowly. > Ok >> 2) why project-try-vc still takes so much...? Specially for unfrequent >> vc systems in our days like svn or bzr that I am not using. > >That was explained on emacs-devel. However, ... > >> 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. > >... 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. >More importantly, what is the profile after you remove the extra VC >calls? > 790 83% - command-execute 631 66% - byte-code 631 66% - project--read-project-buffer 436 46% + ivy-completing-read 188 19% - project-current 188 19% - project--find-in-directory 188 19% - project-try-vc 135 14% - vc-responsible-backend 135 14% - # 135 14% - vc-call-backend 135 14% - apply 105 11% - vc-hg-responsible-p 105 11% - vc-find-root 102 10% - locate-dominating-file 76 8% + tramp-file-name-handler 26 2% + abbreviate-file-name 30 3% - vc-git-responsible-p 30 3% - vc-find-root 30 3% - locate-dominating-file 30 3% + tramp-file-name-handler 41 4% - project--vc-merge-submodules-p 41 4% - project--value-in-dir 41 4% - hack-dir-local-variables-non-file-buffer 41 4% - hack-dir-local-variables 37 3% - dir-locals-find-file 27 2% - locate-dominating-file 21 2% + abbreviate-file-name 6 0% + dir-locals--all-files 10 1% + dir-locals--all-files 12 1% + vc-call-backend 7 0% + # Only with git and mercurial backends and with 10 remote buffers open (in the first profile there were like 25). Remember that the times grow linearly with the number of buffers. 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. >> VCS changing is not something that happens very often to require a check >> of all the backends everytime, several times for every buffer in many >> project.el functions right? Specially when using tramp. > >Once again, given what you say above, this doesn't sound important, >does it? The slow processing is elsewhere, and without seeing a >profile with VC calls removed, it's hard to make progress in this >matter, or give you some advice regarding potential reason(s). > Reducing 3-5 minutes to 20-40 seconds when there is only hg and git sounds relevant for me. Still slow for a command, but important considering that it is still asking the filesystem for every file/buffer. >> vc has vc-file-prop-obarray; maybe vc-responsible-backend should cache >> it's result there to avoid repeating time consuming computations? > >Again: is this issue relevant, given that without the VC calls the >code is still very slow? From unknown Sat Jun 21 03:29:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#49264: 28.0.50; project.el+tramp performance issue Resent-From: Ergus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Jun 2021 00:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49264 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 49264@debbugs.gnu.org Received: via spool by 49264-submit@debbugs.gnu.org id=B49264.16250113189549 (code B ref 49264); Wed, 30 Jun 2021 00:02:02 +0000 Received: (at 49264) by debbugs.gnu.org; 30 Jun 2021 00:01:58 +0000 Received: from localhost ([127.0.0.1]:55969 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyNfy-0002Tw-Dj for submit@debbugs.gnu.org; Tue, 29 Jun 2021 20:01:58 -0400 Received: from sonic313-14.consmr.mail.bf2.yahoo.com ([74.6.133.124]:43913) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyNfv-0002TX-Oh for 49264@debbugs.gnu.org; Tue, 29 Jun 2021 20:01:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1625011309; bh=EqRW6YirdOg81X5igmaWIywu4/rACWUoRm+vlng+3sE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject:Reply-To; b=kA/0IduXXOmJdTvm2DzTUyKsHjOD0CxVA09snzlTOXOfV3C1zeji/8RUhHJ6TVFuFHCsW/kAx8BBbItwZkpPlijDXNMUM4dU+ph+ZmD041b4e8SUcYq3fFmQ1tMlcV0ucIl7xoLad4j8KYwVKbrwsy4RYoRfLIev9WU4NtsgTu2pxZQgxmjPP2/d5manDtwy8mpmld7wQAa7qZlCrGrXDuwen9B7KZQKpGEM+LMu74Pie45k645B4JLiJz6ZaExqKB35YvtGimOxApn+AptFVJALA5L+o9LSvSrl9C0/rxF96FZyId3ngVYxrzN9iVrsAeQNwYrzwyKp4uptKugcmg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625011309; bh=8ZqG1CAmQP0mDkAegwHMcFcwIkN+VqelIsffoCszDRg=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=ahCHQG2FX09dU+EBJLP6+lUqd66edEVnDyOgRv2ZDSkken7sP+TQ9/ly8odU7i1OYQOBBbzA9lgQGOBwdgY8HY6ugiX0GXQb9huawq4omuUVCW/bHJ3QHXzgLXN7gjV362SCWjK4TqaQsZy6EapO+7fLsjrxxDIh2EL9H00rrDPhlWyCf/Qv8WVm7f6t9javjos+4/ISilwAd9eFAPS33eIM72JA/3PS8pM0hITlsVRN/YHfR8rUyHJHuT99F1mrzSnAawBM/GHnfhUQYN1gmEB4nAAMHerb3ZJNU2celiAlDKFU1yobAr+hwAa2rLvlct2cWaO/WAcknkIVbmV5aA== X-YMail-OSG: HLF4qaYVM1mSPKzIQ9_Oiz00BFK6CmlJad2iUQjJgUlRNyHeangd4xyT0FL8289 rebB4QwqMbHt4EuI3kVR5EoxqDZ.rrBGiIYGLN3G0.W5xYFOwwGDe.IV0L_T2lHvk6JRcPn4iK_2 iR8O1xuXVlWFCtVnsABMVsOQZaDrPvW4Z006FZ8W2OpTQuD9LKaLi2luoR32YM2ryKs17LMhhEYF 5uVOmqFGENkIzbBrPaPo8AgwFdX62G4sADfBu0WDNrdXx5d.0jJqLSUSoEE_ngMuLwlVLtssPM1j cn41kH_UjTfURzuyKXHkF5oaW38waFOTD8UCLF8oBTBWK8kJZh0FakjKoAevOYLh6jD5LEjFrSXD dE.X5FE1E1WoGjsADgcJl6i_gbHbNNtVUMGEd8rljhI8K71KG_HRWs20jpTQTHK0LYBHSpJhG9UH BEJoyXgEHYfMByNOn.o6a1mhF8Y6N4L4YnlZcv9XXmYG_5Oq7bxf.F5nAHW4zy3nU_uSqgpBhkOL FENuRVfLB_snLeXDeIWS_1mTJFdTjtGCpTYLSGgZQWUvCk7Wo49lJQeOmvx7ivgP8r4l3Lp91_nl 5fSZVH67h9nr85NVHszKrYUpSVsIpPMXF0ZhLTZ54f24_1qWWJAtpX0QyovHBwafBeTSpCskPORd PqrwfJLXzGWGJgmulPv7Iq.tHvCIpmnEeVa_N_JUGe1m1HDRpaoYoPpa0kQYQROcmVAyfznzMyFE TR_KlU0Xl9tvhX.qKuqWR9.Qo4UGD.m07psg436_96fEmacZZGFXu85dFaRC.jue6vu0IsPX.nwg 2SBUCTxDjIP28l1gQih_LGnHDO9kjOt0tI9NMZF_37C7Dj4L3mVRXrjG3_EQIaYOm2o6TPk6xxMZ UUl7A9xwKaDJzvzQvVUMjMAptBxKvSNBH9MO1gflsVcMLOInQAS2jQOobCWPDw6bKhuiKin6_zvn Ql4r576Ild10qn0Es_.w4DmmPgWxEoiDeiePnmuGOI8Ad6CCl5xTSaUP5OOHltGn.Pe.TSVNG0SY retPrifBz65ff9D06.qIIIL4WgZ3_XvbwfZZWBslx6OtZs0pibEttsBSQ1HIiItlX2xSEHrqvAL2 9HluKn3X4GjDugdLxyx7VNaBLskf4FbmwllHFvVR6RySMJDwRR7AVorYaSnl9292PCQ0NtkrCyRl Ej81Mk.m_9SBMUbuIxnlVO_jU6e9HkfCL3ABCKIXeDGsjIxaV841THVZboYjj2noKjc8KSCWI5R. GAhbmD.dwedKtIV_47GIWN1fjzZiLMvKkNhz_cy3kHw5k0kVEQOSf8C51W4Z6Ja3qWRfplqGeI8P srQ9em5dIrq01u3jM9mBAKb20rtrhs_jSUNirRbFwZsvsZE_nmefVzPy6PyocV48ErclW84T6zcI 4QWRcWwpe5kQYXcfmRN8RxGw7rnwiSK14dnca_Kqplzx7ziRa.ihExVtrNO8_yFztmjwwq44K4Fs wt_orRUy5SUku824FdsSBu1u.SmDzgLRFNij0CZqm0IL1QFnlVFP59hY52UIW2v1s10APLVHZ39t dBvKlZnFOe9FYtCVAL07ZOBEv3OYPMBXBQ2iB0h.yxfISwCPE_aQRrw.yEjlgJutUu8jp17vsDE1 kUyYLpKixp2XZFEqfsjdVA.G1XrmqPKybikzGWd07HggLvjIt9LGvuyT.MXjoHdi0.onjpinJKU6 aJu6JU94MJvYNHNot_jLuGXuC8SM_GX_xv2sdyUziGemFaPTJmjL4qTsMBG8m7iJtkwsZxTV05FG CjJvXI8Es1GzDqVOzA5PJCAXP5RPJAJAxYSp5xZHm.Vzki.v76nyxHcQJeVYcq8hmYiyPUuJ5ue6 dtwjVmLmgA_SYxITqdRe_74LLnCiOQ9rLLVJTr.oxAVUxvwmj8v9cFWB2jlMOh6synQ77O3oYBGf 8_hUZ1zsxdOb0eMbr_GTD_cnyK3FDPMC19DCEBgPZ9uPeNHJvR1O.v038Q8flgIQi5.748krfgfa XHs_ue.egobm2j1F_vZ72aAw557XBRsbzmbC23H2sAiyhn36__EtPKvnxGqU6og7TS0veyEaLs5w FbVv4yi0jLfZpUuToV5UxC4Oa0VYgdvg09fAdTFUzYZyXoR_Rp2ccNGSGKIYhw7inI6s5OFbO2hP ciQF.3wC7EqddDs4AwBSr3xi5G43jo.6JtRr9GQGG0ZjfVqVUsvJYx_PpRZqJKVffDUEPwXuSvNp KlerUGpmqE231YTS6Hz3frFJKotQsg0kNedyC6M9qK6Lx8FDeEl2H2fikGSs0HezeR.EcmBbCeN5 vkEtrgslEgFpbUx0awWVIZEYgRHgyQR8WOU8BrtL7KL2s1D6WB2etZyO3_rKyD8RW4QzU1qKhNuX yJyVie_NCkwYb4ErB2Kqbrmv8Moczl9ivMv716KoqolNPZZKN X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Wed, 30 Jun 2021 00:01:49 +0000 Received: by kubenode527.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 13e9fed445d0719f034e7e6e061c8855; Wed, 30 Jun 2021 00:01:45 +0000 (UTC) Date: Wed, 30 Jun 2021 02:01:36 +0200 From: Ergus Message-ID: <20210630000136.o2uqaa3ldxxtn5go@Ergus> References: <87fsx13aiz.fsf.ref@aol.com> <87fsx13aiz.fsf@aol.com> <72c1b336-ae02-36c0-db40-f608bafecdf3@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <72c1b336-ae02-36c0-db40-f608bafecdf3@yandex.ru> X-Mailer: WebService/1.1.18469 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Content-Length: 2882 X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Tue, Jun 29, 2021 at 04:00:02PM +0300, Dmitry Gutov wrote: >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. > Only with git and mercurial it takes: Elapsed time: 3.018998s (0.109912s in 1 GCs) With the entire list in vc-handled-backends Elapsed time: 8.197923s (0.507396s in 6 GCs) >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. Another (and maybe even simpler) optimization, may be to consider that all the buffers with the same default-directory should have the same vcs and vc root (and probably belong to same project). (I think that all vcs backends only do the search based on default-directory at the end.) So if the association in the cache is for `default-directory` instead of individual file names; then, less files will need to evaluate the search of vc root, and vc-backend only 1/subdir will search the first time. It is a very good trade of IMO. This will reduce the time even the first time we iterate project-current over all opened buffers if multiple files are in the same directory (example: sources in src, includes in include and so on). And I think it will cover 99% of normal use cases. This won't affect nested projects, git-submodules or similar, because those will be in different subdirs. From unknown Sat Jun 21 03:29:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#49264: 28.0.50; project.el+tramp performance issue 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 X-GNU-PR-Keywords: To: Ergus Cc: 49264@debbugs.gnu.org Received: via spool by 49264-submit@debbugs.gnu.org id=B49264.16250571932135 (code B ref 49264); Wed, 30 Jun 2021 12:47:02 +0000 Received: (at 49264) by debbugs.gnu.org; 30 Jun 2021 12:46:33 +0000 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 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 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 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 Date: Wed, 30 Jun 2021 15:46:26 +0300 Message-Id: <83sg0zmsf1.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <20210629222142.jbyegdo72wkp6vv2@Ergus> (message from Ergus on Wed, 30 Jun 2021 00:21:42 +0200) References: <87fsx13aiz.fsf.ref@aol.com> <87fsx13aiz.fsf@aol.com> <83mtr8ooz4.fsf@gnu.org> <20210629222142.jbyegdo72wkp6vv2@Ergus> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From unknown Sat Jun 21 03:29:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#49264: 28.0.50; project.el+tramp performance issue Resent-From: Phil Sainty Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Jun 2021 13:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49264 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 49264@debbugs.gnu.org, Ergus Received: via spool by 49264-submit@debbugs.gnu.org id=B49264.162505951514946 (code B ref 49264); Wed, 30 Jun 2021 13:26:02 +0000 Received: (at 49264) by debbugs.gnu.org; 30 Jun 2021 13:25:15 +0000 Received: from localhost ([127.0.0.1]:56889 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyaDL-0003t0-6P for submit@debbugs.gnu.org; Wed, 30 Jun 2021 09:25:15 -0400 Received: from smtp-4.orcon.net.nz ([60.234.4.59]:37365) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyaDK-0003ss-9D for 49264@debbugs.gnu.org; Wed, 30 Jun 2021 09:25:14 -0400 Received: from [10.253.37.70] (port=41403 helo=webmail.orcon.net.nz) by smtp-4.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1lyaDE-0000Df-79; Thu, 01 Jul 2021 01:25:09 +1200 Received: from ip-116-251-162-85.kinect.net.nz ([116.251.162.85]) via [10.253.37.253] by webmail.orcon.net.nz with HTTP (HTTP/1.1 POST); Thu, 01 Jul 2021 01:25:07 +1200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 01 Jul 2021 01:25:07 +1200 From: Phil Sainty In-Reply-To: <83sg0zmsf1.fsf@gnu.org> References: <87fsx13aiz.fsf.ref@aol.com> <87fsx13aiz.fsf@aol.com> <83mtr8ooz4.fsf@gnu.org> <20210629222142.jbyegdo72wkp6vv2@Ergus> <83sg0zmsf1.fsf@gnu.org> Message-ID: <116428124d5c9911116bc992b360f2d7@webmail.orcon.net.nz> X-Sender: psainty@orcon.net.nz User-Agent: Orcon Webmail X-GeoIP: -- X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On 2021-07-01 00:46, Eli Zaretskii wrote: >> 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. It's probably worth considering that while one *can* have multiple VC backends active in a single directory, it's *extremely* common not to. If there was a user option which effectively opted out of the multiple- backend support in favour of performance-oriented assumptions and caching, along with some mechanism for flushing the cache on demand (advertised to the user as part of the user option documentation), then users could then enable that option as a performance measure provided that they were confident that the default functionality was redundant for their use-cases (as I suspect it would be for many people). -Phil From unknown Sat Jun 21 03:29:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#49264: 28.0.50; project.el+tramp performance issue Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Jun 2021 13:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49264 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Phil Sainty Cc: 49264@debbugs.gnu.org, spacibba@aol.com Received: via spool by 49264-submit@debbugs.gnu.org id=B49264.162506015024687 (code B ref 49264); Wed, 30 Jun 2021 13:36:01 +0000 Received: (at 49264) by debbugs.gnu.org; 30 Jun 2021 13:35:50 +0000 Received: from localhost ([127.0.0.1]:56990 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyaNZ-0006Q6-R0 for submit@debbugs.gnu.org; Wed, 30 Jun 2021 09:35:50 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38196) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lyaNY-0006Pp-5x for 49264@debbugs.gnu.org; Wed, 30 Jun 2021 09:35:48 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38542) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lyaNR-0004lT-ME; Wed, 30 Jun 2021 09:35:41 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3953 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 1lyaNP-0001Q4-PX; Wed, 30 Jun 2021 09:35:41 -0400 Date: Wed, 30 Jun 2021 16:35:41 +0300 Message-Id: <83h7hfmq4y.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <116428124d5c9911116bc992b360f2d7@webmail.orcon.net.nz> (message from Phil Sainty on Thu, 01 Jul 2021 01:25:07 +1200) References: <87fsx13aiz.fsf.ref@aol.com> <87fsx13aiz.fsf@aol.com> <83mtr8ooz4.fsf@gnu.org> <20210629222142.jbyegdo72wkp6vv2@Ergus> <83sg0zmsf1.fsf@gnu.org> <116428124d5c9911116bc992b360f2d7@webmail.orcon.net.nz> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Thu, 01 Jul 2021 01:25:07 +1200 > From: Phil Sainty > Cc: Ergus , 49264@debbugs.gnu.org > > > AFAIR, that's not really true, and ISTR project.el aims to support the > > use cases with several different VC backends. > > It's probably worth considering that while one *can* have multiple VC > backends active in a single directory, it's *extremely* common not to. I think Dmitry once told me this isn't so, but maybe I'm dreaming. > If there was a user option which effectively opted out of the multiple- > backend support in favour of performance-oriented assumptions You mean, ask the user to specify the backend for a project? That could work, I think. But again, Jimmy's use case was unbearably slow even with a single VC backend. From unknown Sat Jun 21 03:29:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#49264: 28.0.50; project.el+tramp performance issue Resent-From: Ergus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 30 Jun 2021 15:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49264 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 49264@debbugs.gnu.org Received: via spool by 49264-submit@debbugs.gnu.org id=B49264.162506584719330 (code B ref 49264); Wed, 30 Jun 2021 15:11:02 +0000 Received: (at 49264) by debbugs.gnu.org; 30 Jun 2021 15:10:47 +0000 Received: from localhost ([127.0.0.1]:58467 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lybrT-00051h-1y for submit@debbugs.gnu.org; Wed, 30 Jun 2021 11:10:47 -0400 Received: from sonic313-13.consmr.mail.bf2.yahoo.com ([74.6.133.123]:41455) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lybrR-00051V-PZ for 49264@debbugs.gnu.org; Wed, 30 Jun 2021 11:10:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1625065839; bh=NPSobimR8mROdz8XoORH96x/vSWfecJyZjOdZTJmSGI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject:Reply-To; b=LdfhvTahGoPeassEMdlUCStS4m0TSx44gFfaQaq4s7pSbxMpSNLXJ/UQFwonvXYrVPmsd+7Y6h1JY/SM3bPgSVZMtqWQAgVqg4jQipZtbD/e70t4DKf5O0+R8H979QYpoogFMbAChF/1jikqP5imtxXW2Vcff7hDtbctouIsKszfKT0KcCRy4qzQjy47TcnUiTEgtDWUxpgz47h+Qeji5Hdn2TE4rQDx8GzjB9IyaYgmus8rYazYigJDZMwWP919Nl4oFPsrH3Pc12uaBJcbnySHcImVDWxdBQi/6YPf9PXISUZHEEud5x22OgXZx0puB3WV2WAnZCLsG8CH6nFyOg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625065839; bh=WQ9OMYlpb2MFEKfttefuFe9pXnXq9TUprnlOpPfvv8l=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=K7pTvMbG3SDYymwbLl8i5jRDzaDGLLW3vSy2L2ASEcbsljA+Mrj3Wj3iKLcN+hGnVLsPZSsL/uE0h+8EvnpVtO3/gnmK7EAY5Er6mDEe5m8ogvixQvdL3mcBXDNIiRssI343KSkRKlavzIhx9DcTKjZcsCvoVBzMogktEwnZ4EKCBQoG/K4ToKZYsz9/rnfv3cgvrrW/aFyjDRaBHa68xPEEspDBKisEU77PjVxFAdVxPeurU93LD7Ni1I3ru/tqR/kEEN8dMzf11OX4PvrHtOemPPXvFsEkaCOs+m3N4u4MPQ7NVHpbTgfMJMN46EkxVcwwNi1tNfHE0zF0iP9S3w== X-YMail-OSG: fNjsgmAVM1lPNS_3cHIuceXRR_W9cnPBVoCMCbikvuWDIxQaL_li2ZXLXf9RyJs NV6Gmn3PbSl9E84.202DcRR45Lrbv8iXA4L6l7je5owJx8dfIPFemFzcM4EvhJH6IANsSmc2WmM_ TvO7y0B1HuyLs25eYBUbpHUkZuFC2zyfTA4wi3U8cVT9JjQgrw3WmwC.ZKyujDBJ5YhANgB4lMZG ND9lLbP1XZYq8KU2TkmHHEYyxwgo8IsrvMc8Xjs7cKZXaY_og76vqcr17_rNKwm.2o9VGBSLTH7x 4CGJAIKHNs578Ij1afsomuHNQpXU4iXyvaPmXvO71OxkBm8c_EndxYCueh8xh8RjHREcnRLqMhXw NJ6HWv3W7X2E7Sgrv3fIVUWM54RBHHjzLVSMTKvYKX66fkELG.B6HM041NO1KmdpwHENH7wig.ze uS49Vw5wpLUoZhSGFXa306.q3Mls7N.medMITVCuMS5V5z9yBKEDdlayZbcDPgIhs90cGScUZMRO J42y3sOvBAZAdS.fhHUxuqXDaJc0v2zNhTVKIeKgevupLZlqoeSzSIU6GNuNp.ERtCmXCOnf7ak0 u6PQF1t4cPERr.xCpXfVi7iW6mIEVjPcLRlsERdMAOoMO1Q0VJTCEkHP97wzXh8NgGJWt1akXYwh DhiR0x78Wt5EkSaqDcBCxWm6V25GSewFJ2QbmD11tmWsF3UZq7tAK1pcINKjwdHYybHZ5p0Hw0o8 XZxUAmnL_kbDTGh2xNQy3t7S9wAlUeYnvjWq6xMPhKs.vQh5_J8QtFcgj789VKjQAZHZhQgC1_rw LU3ebuPu.OkZtkFJNeJJ0q7c_.BkZaONgfB9jd0XZuu1L4LCi51LKlrFi_L39x9Y_YdoH9SXkMU_ Vhb7gKEr_vZ5cMEWbsyX8jb_VbLZH5Def5HS3nGDz0FZS3te7vTknap7t.IPPTKYk9PpSGZ.lTM1 oLs_lEPPwjboL6DLe_9DqlcNmjnsr7L9INynqETM0o2SYk_zXyHUNNHjvSvU7AWZNpHEUCvNbmXy UOF8rTILNmz7ZcabPEaNur.65XuW2BYOk0mUflLPvrotF6sqVwx6IzpSF0qC4PCwiAy7DIgRhmQo 1Vdb7f1ekSeWxu.FdRdjHS3RimHjviksQItW7.GY__w2lqKpPKuftM6TYPnL7CcvWQeSDEaSd2xN PpsmhAReGt8Vm67qIKC4c2r3TksMn33w1ek2h.g6Xrh5LTPFJBTi5Qi0qxw1.hEoiRuPKTNxyrt5 QGaIBAYV2i1zlDLsahtAQr9UFwjOQ7KyWk_3nVF_n9Kqr0dBABv6JrEUA.Y.XSR4VrEUNBxwNA4r ueV96r8BQPy4Ccz.nUb2tDDYkITHtPqydX8OD_j7bJdW1YTvDPsoulRv6CCc75HrBMqALmLla5R0 CXgGr5EAwo_AFT4KbH7XdXv0cavkKXo3MgFCBvBjTg4dkg3OBvllPw5JN_LBZFD2THLvAyS5cP3V G_iW7iYwMHX3tZKf8UaL7X.cuAfGQ3E8mSJJSA7NSz5qHtEV5nX3Kmboy0bEfW7DV1ewTu75xXDl 2M6D7IyEL6BtaLSpMGI7i.W5QSCNSRpDEuBC2UOpB8dWpHxPCss4v5fpXJqPigc3H1tqJv92IeSv 7LYfMc1KY9svwH9wxyD890UIBFqxc1OipKxFn.L5itYqNOsN6vOQ9ps7ACUo9FcQIjKB1dJt.95w QsAHfQj_X5agsF8qXG8YK2Rxa3KQfBMyjSmphLWjc5XaWRJWFxqh7F.ZfmkdEmYAgnoyNlAWh47T daJbKHR_yVfgtiBVQ61wySOjVCjE2BE90dU39gPS5CZTGNxUaAeA8dIHDRa4ISIQnw.xu_a_1By9 wbItGGBGIqsGQ2z10vbnX0YqMAd.pRKR4tAxdeU5gG4gHpgP9bZ9OVPTpSVMiwCbtgC8t3.J5W4K aulkzUkunsEm1TkWIfkicfrbnYYfPQ_FhMbEY5tUOj0gyCTcamfDsmHDZ1AQHmCvR1YtXWzKHCIR 8maxcOQGnr4aTXfwhDrxRLap6srHagoJuOvHwv_mOtE_zMmla8Ux6kLBp2_PH9dlIsgX5Z5nWIVp kZzdCPJxM.HH88LY8NBKXktUZ_lxRtbWUUsX8eAj_iRxSrsmngZBAd1qHsgsPvXaYFVRYl6S74RU Qj4NAyeDRnYzmMkwShzU8yTT1UYZ6ik6_tPNav5Rkigm0VWrrIwY9NxDCV.fZ5AkeNEDP65VvM.g biXP773wk9xhc5mlLuz4YtV0U8Ktp5fIKM5ConaPFsRWy6leLttR9STw9_WyWLgIcf2xL_iwNFka 0Fq3mApNApuG4ye33z4avu7QBEYhKq4vBu5sUFyOoUOTRteP6kZEz6tWGU.v5IbuQpN1gBzRm8qM 8pO2xdJ1O0l9yWpr4e.wWMA_M9oNmfbVZutM- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Wed, 30 Jun 2021 15:10:39 +0000 Received: by kubenode518.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f4b54442e6dfa5939f3d42a2a6a48fdb; Wed, 30 Jun 2021 15:10:37 +0000 (UTC) Date: Wed, 30 Jun 2021 17:10:28 +0200 From: Ergus Message-ID: <20210630151028.hi6eb4v4qvrjihh5@Ergus> References: <87fsx13aiz.fsf.ref@aol.com> <87fsx13aiz.fsf@aol.com> <83mtr8ooz4.fsf@gnu.org> <20210629222142.jbyegdo72wkp6vv2@Ergus> <83sg0zmsf1.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <83sg0zmsf1.fsf@gnu.org> X-Mailer: WebService/1.1.18469 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Content-Length: 4262 X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Wed, Jun 30, 2021 at 03:46:26PM +0300, Eli Zaretskii wrote: >> 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)? > In the test Dimitry requested I sent the numbers of eval: (benchmark 1 '(project-current)) Only with git and mercurial it takes: Elapsed time: 3.018998s (0.109912s in 1 GCs) With the entire list in vc-handled-backends Elapsed time: 8.197923s (0.507396s in 6 GCs) So, ivy is not the problem. >> >... 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. > Agree, but it is another symptom about where the problem is. >> 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. > I can't speak for all the possible configurations; but IMO the most common configurations around are projects with single vcs OR projects with subprojects (git submodules) in different subdirs I am not aware of any project where different vcs are in the same root directory... For sure I have never seen that... For example something like: project0 |- file0-0 |- dir0 | |- file0-1 | |- file0-1 | |- subproject1 | |- file1-1 | |- file1-2 | |- dir1 | |- subproject2 |- file2-1 |- file2-2 |- dir2 | |- file2-3 | |- subproject3 |- file3-1 |- dir2 |- file3-2 Again: IMHO if we support this configuration we support 99% of the projects around. And I already proposed an option (using the default-dir as cache index) that already cover this with no functionality penalty. >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. > With my solution we only impact performance: 1) The first time we call the command AND 2) All the 80 files are all in different directories. Otherwise there will be some benefit either for files located in the same directory and/or the next time you call the command (or open a file in one of the directories emacs already knows about.). >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. In case you are interested about the issue with the external package: https://github.com/FelipeLema/emacs-counsel-gtags/issues/29 From unknown Sat Jun 21 03:29:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#49264: 28.0.50; project.el+tramp performance issue In-Reply-To: <87fsx13aiz.fsf@aol.com> Resent-From: Ergus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 26 Jul 2021 16:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49264 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 49264@debbugs.gnu.org Received: via spool by 49264-submit@debbugs.gnu.org id=B49264.1627318597663 (code B ref 49264); Mon, 26 Jul 2021 16:57:02 +0000 Received: (at 49264) by debbugs.gnu.org; 26 Jul 2021 16:56:37 +0000 Received: from localhost ([127.0.0.1]:51393 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m83u8-0000Ad-Oz for submit@debbugs.gnu.org; Mon, 26 Jul 2021 12:56:36 -0400 Received: from sonic302-2.consmr.mail.bf2.yahoo.com ([74.6.135.41]:37727) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m83u6-0000AP-Lp for 49264@debbugs.gnu.org; Mon, 26 Jul 2021 12:56:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1627318588; bh=DmkOnp5BIyCj7k2LSA825M9szkX7Gh0BcKWOHKvJZzc=; h=Date:From:To:Subject:References:From:Subject:Reply-To; b=rKJLcthar9hGkFyXHhK+mts0j7Y6gDsA9v9nEqJTLSRq0GJW0+lgIdf4vl42Ks8ssBpXcc/24YvW2FuotaF1KGR0hCMVGzTsrZE9S/SgfaeY88coLw+z/fiSdseIeSD5u7d4JpOAO64KPQeAmZ1eIwRtyly6kU2EJMp/ygwB+0Fr4V+GFpKTqO6pTtsyZsrZJoStGm7YBrhHGCqD6JyFa1JwCKYAbrTtKJQGMTmz3B1bt53lGvabnDWN2EG5dCHyxtoSaedsylflUXha93tVJ6ks7WFfNDbt4SAHqKgw/rIlxG8QaU5Fyw2NPZzYnTTsFv9OI2BrCzw47/n70MQNFQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1627318588; bh=pV83GahhMs4VYsdwvkoWUMGv8vCXFQbHrQDX/BtkA1X=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=SWb5B0J0Ip2MMHqtiMMJHD50Gw051m3lYWqrQfdCThzslzd6hBa2KA1kABg5TEF8gndHDTuj/HgrTne2aYpQOY8qqexL9oj73EcsWS9W4H+nS6qcFS0mhS7SFluCz0TlMXdhTuRcLbIfpcD994Td3WS0+XOq4gU0yUzItadHFbMJjVE5DUTkKgGW5/XjdIrUihzV8VGe7BrT1IywHUSlPjNJNQzzYWQ8lOFTvWC/y0z7O+OCQWnEDVv1F8bTOR79Gz2MxDcEALuxvDB0CgTQa7pw+CZsqSKSf8VzLvb3iAXTFaillSYjtPULwIaWaR06O3pWiWNq8Xy7THLdadnm7g== X-YMail-OSG: HgZdk84VM1l9eky1JTckmwxJb6ujHSw.0xXVEmUMUaUyL_dikgc.AdwbkiBmMvv c1jGAw7bA0MyiToSNJ6Wf_uwVaAui07SM219_dJgDeFh4iLfPylZ3IYv_RsnYgdoSgWgmFLE0Y3i WqqaWSIIyw45qI4YE6MxYNEuvPfr67ljcz_qWQWxlURZp3w6nH.sPPXbryzmVFMZvxmsjjVC_BTf ZSkcF6.XUtyvZnAcGJYlzPlRdo9Ri_.DulCT6_4.s4smScCfnps9IhzSRag9ybCKVZvfJ_jH5vfL _cMPniYH9kvMColdm845mzi2ZA8McJMJ8hBOzeXzl7LLBOjO4H4pumZYRdn2omwM1IFDyiGS1fZO 1xHaddvFbwjzpf9fQKJkmM1UhlKcTZqxGFzaMjAfTaz7RrABHA0Z.aISTf2Zu.F1o0gMCTDXMNtk KT.gCNezwNiFKJVF4dS.btezDTc3Jd_nfD60NLidR1EOGOJgk9b5EPZteFntV2HWnkx2f5yY5Ext VQeN2SSoWRq0w4ePkHvU02xNZXuEgU5gWEoWccUD7jE8bQCQOXMEpjOKhkKNfmlitiFljLwnsidD ev4X8aQF3rwq7TJIuEiqsdq2G708X7J1PEcOhUrybA5zW27bOeaOExuNbhz4YX0Y5WqSasc.ltXY tFPHUy19v8zLQjyv4ehdK5TXSaHx.rtM7XqVpJixCyY9uvGftieBnxU0z1jrVXjH3BVUmWoe51Xm Ha98PQ1znpt.goycIEE7TFngstRQHfNvyb3mQ5TY44bCy0jKClUIULGytCJPp6wNUILKIbyuNMOO tyCh7x9E.ky05V6yJdXAx_OIbjxFDLf5A4Dtu4.0qsjZrVtZKI8OLyJU_LmdJ85kp0XstQP_pYoQ krcwM8672PHGEbUk6GU8ghUTEERvZdemcJfpJ1C9zgavdoK5M_NivbDqfGuWj8.Fxt1iC7qKiOCO 8L7cFPR6rbxApEPqs8RJ7jr.Ide7DHbpZ4CUO9U0EfR5mpSYr48_NuOEy42jqUaOUnG1yFtRQ_C2 QtlEFcBc_B7pFZ_.mhKA5h4uN1QYGWEGLmTekJYzXDx8hPNuIiD994hNdqn9px8MT0ylqQFfn_ZL iwRtZ_miPyrFvCxQJoQduyUXstGHRCFqY_SRanjOdiBz..Xtr4Uxf3VTz6WtQs5kxE7SmYFs3o5G gwbuWLuIm.aOz1mnxhxthBOSsN104fapKdYS_IFXd.hxnv4K3m1K3KX6EIGsXwygwRv8FRY_1DHi gMEViuM40RLZQ0F8.RLjYSIpdf0flCUwrI8GWFLJGYJ1e1_KzRLBJn2CxStxKCT75UT5u6ihxyZD YWbbAdC1RzQCSyNEA535pk9yvsWawo573RSRPtPCLWQ1IGHhneX3msFRWbqWn6cLJx4PaaLSF_cm aAIF9fGXw3.rbTph9pCUWbP_NuJkQ4pRfyLWwYaiNf6z7zmGaQ_VsGc32ZRV1LrOzX8Jq4XhFqX9 uCW2qkRkBkEttAgLSa1kUXKIMJt3D9HjSOST4K4y9uO871mANnMlbpCYoD9PQCNPG1e.NUyo2reF j1erCZTZZ4KpOev6idP66AccwLtdlFPtVX3M6lkEo2_V9wwMxHFP3hpw0m3yF7lF9NeuT.SpbsR. 1sbIKLQTqsoLj1UyOg1TYlA9pl.eZUCdIgQSccu77VBFmiUxzvxdR_yglMnQ4AYPZOCy90nzyjy1 ARiKC3ZDWSIfIzRQMvE.omBVt0czK8QlYQEuvbdj0FU8fkYPLW6lgNZWWt9N95RcEBUNchnC2lLO PZpSXccO2K8jTtF1HQcEer_t9r_C2C15kUQSWg7F7xsHSxOZIFZzPxlw_awHEkqUtNEyxB4sFw0T tbNkpw9IKkhGB7A39_5rFMV9Sc_d_NsMP84aRj8NVy_icW47mjZXvG4Q46VQUIG79SKzdtR2144d Jdc3it5f0Ehomnmsb6hIFa4u5xyQITTGqUdjUSq7nyLFWNnW4NrvTc6H9CUSb9C5hv0W8sBYrYH9 AIUtCpMoZP.TWLGY_iO3VVJGdacfIPUFAotv7afXlbputeSbMUNPwHreGhXXvysAtxIc14LZf5vF anm2gmm2AWDiNOEOxSl.r7K4COOE3g_Is1JZ4ExKXRmedGot_8vz0ui_YkDyae_EB6edpaaale12 4kZSPlGCSLK9nwxOZvHt_5.aV4oGKeQgyET5WHiSlfkI8kQfNPHCBGMS5NyI7KcZNywNT.ZzcGbT vX5hv4BvMgFT2yjyqUnekv2YB8bi2FzWiLQbPFQvOmk0MqZSMNTNV_rKlcI0nboj6bVZa1p6vWAe qC9Q_KU7GBtBSvis7tzuD_lwPsu6C67TO4kQ3OksQ7Eb03AQpn.DoOCk- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Mon, 26 Jul 2021 16:56:28 +0000 Received: by kubenode536.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID cf410e62c9a2f08599e4fed523cf80be; Mon, 26 Jul 2021 16:56:26 +0000 (UTC) Date: Mon, 26 Jul 2021 18:56:10 +0200 From: Ergus Message-ID: <20210726165610.7pjiyuz4vtxuhgq7@Ergus> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline References: <20210726165610.7pjiyuz4vtxuhgq7.ref@Ergus> X-Mailer: WebService/1.1.18736 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Content-Length: 39 X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi: Any progress/suggestion on this? From unknown Sat Jun 21 03:29:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#49264: 28.0.50; project.el+tramp performance issue Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 26 Jul 2021 23:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49264 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ergus , 49264@debbugs.gnu.org Received: via spool by 49264-submit@debbugs.gnu.org id=B49264.162734070211600 (code B ref 49264); Mon, 26 Jul 2021 23:06:01 +0000 Received: (at 49264) by debbugs.gnu.org; 26 Jul 2021 23:05:02 +0000 Received: from localhost ([127.0.0.1]:51711 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m89eg-000311-9L for submit@debbugs.gnu.org; Mon, 26 Jul 2021 19:05:02 -0400 Received: from mail-ed1-f48.google.com ([209.85.208.48]:45916) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m89ed-00030R-Jz for 49264@debbugs.gnu.org; Mon, 26 Jul 2021 19:05:00 -0400 Received: by mail-ed1-f48.google.com with SMTP id x14so7969706edr.12 for <49264@debbugs.gnu.org>; Mon, 26 Jul 2021 16:04:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=0WvHN2qfsK5D8arGjM4KcSvGc0FRkyN0F2RxKImUHWo=; b=IfklKo23/8om/lUHkKnJR1E4NomFH5lDDz4H7aMeNXhZ3ZYg8Byp9mgHF3eghcr1hQ p37gJUR/v6QCTCwhdVD+LStYUomYa5leaiRw7ax3BD1FcrO87xOs81qhYAHqIszaUlZY iaPe2pA8IqjDFtcvi33EIg/4zKnnwn6jP0Vv423l8r8TdlirQF9SC0EyRULqHgwgwVzm ceP1w8X1RIzJamlg8pyvH4JImPvHLyMHOHHS9LvJJZAKmAmwpdJ15IGRCo85i/r24yDP CxopCtQYKijnw+3WjogU3bMgSCaJKqqzb6QNXMFlur6BbHsdZy1oPCD+eAILsdKgjv4d Klhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0WvHN2qfsK5D8arGjM4KcSvGc0FRkyN0F2RxKImUHWo=; b=RNguRVH0TwWFVp2Q1thl7Zl5RHqNTw4XgckD/BbRPksgCNQOa+mdGhHYtBrxZMtr1y agX+DbMr4mk3mTObRLRXk4T7FGW2arDtnYJZ2LFXbDoPAdOX+lwVABIgUA5kr1AoIGpU CunfRvh05p0UQ43uo+9WM9A6chpSIDh1MPsLoXgsSw5yYvN80QIZaUiL+3CDIz9pxnx2 +STL11MXEpKxAu6h4GUdUFD8xx6ygUSWHQu/0W0Y4XyXNFfpa9LRbGhHWWJcPeIbj9kQ tMvZGpNgcWa7Chxlk7rWboS8tXzvYWqvERy769xiivJv4q0SUD6RQxPIZUIVEm7TebrD JuYQ== X-Gm-Message-State: AOAM530gm+d5IuHRGmTkKVJr+5eWDyZJ5sPBOzqFquETbLL9fP9AxGTt BYO9ZfvLzKB5VNwsm/RpuNQiv9BC03Q= X-Google-Smtp-Source: ABdhPJwFiOtuZneNyOKReCDWf4x7GKvmdiyc7FYDH4Fnbaxa1w3FqJ8QScijmUGyVMzhNmCYedY1bQ== X-Received: by 2002:a50:fb18:: with SMTP id d24mr13903327edq.225.1627340693700; Mon, 26 Jul 2021 16:04:53 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id cm1sm362610edb.68.2021.07.26.16.04.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Jul 2021 16:04:53 -0700 (PDT) References: <20210726165610.7pjiyuz4vtxuhgq7.ref@Ergus> <20210726165610.7pjiyuz4vtxuhgq7@Ergus> From: Dmitry Gutov Message-ID: <14a3d5a3-33bf-cc82-d144-7302629aa33b@yandex.ru> Date: Tue, 27 Jul 2021 02:04:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210726165610.7pjiyuz4vtxuhgq7@Ergus> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 26.07.2021 19:56, Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: > Any progress/suggestion on this? Only internally. Let me get back to you on this in a couple of days. From unknown Sat Jun 21 03:29:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#49264: 28.0.50; project.el+tramp performance issue Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 09 Aug 2021 01:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49264 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ergus , 49264@debbugs.gnu.org Received: via spool by 49264-submit@debbugs.gnu.org id=B49264.162847080611673 (code B ref 49264); Mon, 09 Aug 2021 01:01:01 +0000 Received: (at 49264) by debbugs.gnu.org; 9 Aug 2021 01:00:06 +0000 Received: from localhost ([127.0.0.1]:55096 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mCte9-00032C-PP for submit@debbugs.gnu.org; Sun, 08 Aug 2021 21:00:06 -0400 Received: from mail-wr1-f44.google.com ([209.85.221.44]:45620) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mCte7-00031C-D3 for 49264@debbugs.gnu.org; Sun, 08 Aug 2021 21:00:04 -0400 Received: by mail-wr1-f44.google.com with SMTP id m12so19148755wru.12 for <49264@debbugs.gnu.org>; Sun, 08 Aug 2021 18:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:from:to:references:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=A04rOq0sx1BGJ8OFKMvS4xHMMqd2gb741nf5aFu5VD4=; b=DnLlsP2v4gyBN1nwIfwua0MN06xBlceupnlz+AYJhQTomZogzNraDF7LECo6/1585N HlynR0Hxa6tG51SGuCSPLWPfjtmPE31OELinaR8v68fOxMdroAyHpsAqoTIpgbgDEGYf TmviGfdeQXGWtzO7EyiVq0LYid2QXp/T04nHEG7mgSEDkKDrzr0spqia/DkocErEGeDh qod9DngEfzpl34cTz2kjGsU2o0tQUEeJAYF19HkxYDhGlE2kCeDq77Y/XhSHI4gj4bnc GCW07pqd+Kr5CpgiNmP2YnB66pdwYw4v8KpP9pIHIx37374GFVWFml0Mv/j8ZxlIli2p O0cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:from:to:references:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=A04rOq0sx1BGJ8OFKMvS4xHMMqd2gb741nf5aFu5VD4=; b=GE3475w0ZuWPc5ey8613MPeKU1JRAW6dZekweuu3MoLl+NKXjMoNdSp6tZzxyolDDJ lErztDQLiUFNtSMAysa1FLE8lkclxWbIThqxHR6YKMtbar9jcCT7FrasTguXWhMs1zsP Q7lcWMDPNwVm56nKvLiX2PWqUcOE0DgxA/aKKFPlf9Er9wfcKQP2c2S75J9NLCUS0g1Z QFPUat3/gy8+ZW3Z+dlkZ7mWp3OTR/1iZulYhSOovWYl+qMWoKRqYgntAluvBxle91EH 9RHinQ6rRxuarLJE+1Hi0ckVOMaiqkIBKiqI+59bc9miyc/QsD0ua9Urr8ujiyExKrGT vALg== X-Gm-Message-State: AOAM5320Gddm8zG79S7txTkkyAgTqCmRT+pq9v5BQ/3vm/0CMzmYjTm4 DMMBhHgQbkFCPFPatJntq7G16/6IHpw= X-Google-Smtp-Source: ABdhPJxbAczRCkq1FMia6Wi3ofC5Yo7e0odVDqBRTMgBm0+Dd+vDKEpoEG7KMdplKm3CElHmWywyqg== X-Received: by 2002:adf:e48d:: with SMTP id i13mr943753wrm.288.1628470797366; Sun, 08 Aug 2021 17:59:57 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id j19sm21361211wmi.3.2021.08.08.17.59.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 08 Aug 2021 17:59:56 -0700 (PDT) From: Dmitry Gutov References: <20210726165610.7pjiyuz4vtxuhgq7.ref@Ergus> <20210726165610.7pjiyuz4vtxuhgq7@Ergus> <14a3d5a3-33bf-cc82-d144-7302629aa33b@yandex.ru> Message-ID: <73afb142-38f4-9e0e-ee46-14ff70db5b72@yandex.ru> Date: Mon, 9 Aug 2021 03:59:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <14a3d5a3-33bf-cc82-d144-7302629aa33b@yandex.ru> Content-Type: multipart/mixed; boundary="------------106241B489F0430531B2686B" Content-Language: en-US X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) This is a multi-part message in MIME format. --------------106241B489F0430531B2686B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi again, On 27.07.2021 02:04, Dmitry Gutov wrote: > On 26.07.2021 19:56, Ergus via Bug reports for GNU Emacs, the Swiss army > knife of text editors wrote: >> Any progress/suggestion on this? > > Only internally. > > Let me get back to you on this in a couple of days. Sorry for the long wait, this feature ties into another old discussion, and I wasn't sure how to proceed best. Anyway, here's a patch to try (attached). It should recover performance lost back in 4ca13d98c9e while retaining flexibility (and even adding more). There are still less than optimal places there (e.g. file-in-directory-p is not very fast), and the modules list is read from the disk every time, so some further optimization should be possible. But first please try this version. --------------106241B489F0430531B2686B Content-Type: text/x-patch; charset=UTF-8; name="project-buffers.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="project-buffers.diff" diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index 4620ea8f47..f164c19ace 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -51,6 +51,11 @@ ;; files and its relations to external directories. `project-files' ;; should be consistent with `project-ignores'. ;; +;; `project-buffers' can be overridden if the project has some unusual +;; shape (e.g. it contains files residing outside of its root, or some +;; files inside the root must not be considered a part of it). It +;; should be consistent with `project-files'. +;; ;; This list can change in future versions. ;; ;; VC project: @@ -334,6 +339,16 @@ project--remote-file-names (concat remote-id file)) local-files)))) +(cl-defgeneric project-buffers (project) + "Return the list of all live buffers that belong to PROJECT." + (let ((root (project-root project)) + bufs) + (dolist (buf (buffer-list)) + (when (file-in-directory-p (buffer-local-value 'default-directory buf) + root) + (push buf bufs))) + (nreverse bufs))) + (defgroup project-vc nil "Project implementation based on the VC package." :version "25.1" @@ -628,6 +643,23 @@ project--value-in-dir (hack-dir-local-variables-non-file-buffer)) (symbol-value var))) +(cl-defmethod project-buffers ((project (head vc))) + (let* ((root (project-root project)) + (modules (unless (or (project--vc-merge-submodules-p root) + (project--submodule-p root)) + (mapcar + (lambda (m) (concat root m)) + (project--git-submodules)))) + dd + bufs) + (dolist (buf (buffer-list)) + (setq dd (buffer-local-value 'default-directory buf)) + (when (and (file-in-directory-p dd root) + (not (cl-find-if (lambda (module) (file-in-directory-p dd module)) + modules))) + (push buf bufs))) + (nreverse bufs))) + ;;; Project commands @@ -1014,13 +1046,11 @@ project--read-project-buffer (current-buffer (current-buffer)) (other-buffer (other-buffer current-buffer)) (other-name (buffer-name other-buffer)) + (buffers (project-buffers pr)) (predicate (lambda (buffer) ;; BUFFER is an entry (BUF-NAME . BUF-OBJ) of Vbuffer_alist. - (and (cdr buffer) - (equal pr - (with-current-buffer (cdr buffer) - (project-current))))))) + (memq (cdr buffer) buffers)))) (read-buffer "Switch to buffer: " (when (funcall predicate (cons other-name other-buffer)) @@ -1160,7 +1190,7 @@ project--buffers-to-kill What buffers should or should not be killed is described in `project-kill-buffer-conditions'." (let (bufs) - (dolist (buf (project--buffer-list pr)) + (dolist (buf (project-buffers pr)) (when (project--kill-buffer-check buf project-kill-buffer-conditions) (push buf bufs))) bufs)) --------------106241B489F0430531B2686B-- From unknown Sat Jun 21 03:29:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#49264: 28.0.50; project.el+tramp performance issue Resent-From: Ergus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 17 Aug 2021 00:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49264 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 49264@debbugs.gnu.org Received: via spool by 49264-submit@debbugs.gnu.org id=B49264.162916118715622 (code B ref 49264); Tue, 17 Aug 2021 00:47:01 +0000 Received: (at 49264) by debbugs.gnu.org; 17 Aug 2021 00:46:27 +0000 Received: from localhost ([127.0.0.1]:51178 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFnFL-00043u-Ee for submit@debbugs.gnu.org; Mon, 16 Aug 2021 20:46:27 -0400 Received: from sonic302-3.consmr.mail.bf2.yahoo.com ([74.6.135.42]:42631) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFnFH-00043e-4b for 49264@debbugs.gnu.org; Mon, 16 Aug 2021 20:46:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1629161176; bh=ZbiMqs2G6oWIYgb+PW6c1OmYeC+VYQiV61KvXNCnbpM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject:Reply-To; b=Y8B2TcZDTMvb9XzBaPxpA/e8gmfm07tVWejT+04I8z57umdnJF+PU8JK/OczgBcr2B633ZtHu+lLCg5tz6WoEDsSzxDZ6ARfmFjxGyUoZKkGaehrvgKQMEUy3Jpj9QGa2hRekt7fJ7J4LmFpld6IYQ9OT1qJBA5SwxdjcppwH8Po5vG3hhP9uVnuiogOjxF1Vw0lI+jgH+lPers0o49n9BihqHLflEuVe9OW/Tv9DgGVaC6232gVqlQx7thA1rnARi9m0JoX/K54T+joDiZVga04KxynnJx5wc2XeWCD4Dj97C/zWjBW1zEpsdJeeCmENfAnT4ZFuZ35TWbGKqiffQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1629161176; bh=IvryKOjnJc/k5Gf+p8IC/1grNzggsUiaTp4LYVJARgM=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=LBWWnpNS3kj2A3M0UfO+Yy/hF4N9foB8j5dg+Qwg7wxjVPwle6g3Fs0lJA/Gcpp4nH3yiWgG5RTtsiAaeTZ1lsYiEaUuHXicG1WNtoDsM5J4ISV9PACncnGEN/TIIH9fVWw1AET806tl24sdqvRQ83rNBoJXyp5p8HwKk+OjAcJsbZDMt6Cdgv5veKDZXVPWRZJXZ/NsVP6qG0cc72FmASNsQd7+1k3BGc/2VMHZDnP8kwlOnX+8RJaURavcLdzRbjUDf5P5QWiBXScGTGDrmHNbXyosOrU/m04lX27Mp5pCtVpZmDRjxt9cUuQAXpRKWJVE3IMH5QtVf/VeebhUdQ== X-YMail-OSG: 7WdxKSsVM1lGf5cta0Z3baXQeZoZDAEl_tNZINV4gCV1OiKlFfkLT12g8iVDafQ U0VAIsqipk5jtB.t76lqVD7GLqzGh6pCWkorzl.9Ouc2G0kvpG6AqpBLKFnVNngdotl6KtOp5PRC PhJCiyykksXAloSuf7BlkqfoaHpIC12Ki5alkWzjbnM_S0gYvRK6hk8zv4efEXc68Hre5_qr3aM_ HJW3iE3lsi3gSyDtz6UwWkexshX2PJ3Xo6ZBDlzzVpsmlRaTkw.hJ0G2u0dGn_fotCmUhVdQBtah aVTQQNsnQ0o4b8urCbkgrrvopgKwV5vlzskYxI5H3qtVg8_pHLEUZgY.uW7W9IMyFf9cAPY5RZoj b_zfFwQzvjxFkHMM4HabNc92FHVsWbQw0cb5Um39Yw6Eh.dwxjA0_.PhiVJUM8Z1nDfv0ziG2EOT fler7Py.n9ubN4xTpQQ.TtSSrKqd5k2S3bS0meuQBljknzTFeJ08svYWPShqyweNrOjxx1FKhXBC VhzXDVdaS.zFdBc0LGQ6xYH2_rsZUE24v8HR_edwQiW.Sfc6PVbJ9uLyAFOZM_s1bEq4SvnQsf2B DIdqcXfdsn_ApsHaMfvGMjvmzfQv2wXF.sDnNj0zRefD4JuMSgXoGM2IpEhrTaMZn3wKrUz5Z0iW YB7yFOKApvTlGb1RAEKdIAXJo769HNzqCB1vZo7eacv0ckv0AocoHUea9KSSa_550oU4rb.0huJh myKzmPScHAD3cXg41zHJwqcgM4b84h6Z7C.j6YW7cpry7zNTLT7u3GnTn.zi0qrheqN.lTEFfMMw Ry_2R2xmDp5L06Y1euWosb2ALRD23ltEb7KAWH9jz.NKx3ilpfYruisk9tt8aymuobl08XyvhRub TLCiOBLziPhdu_ACXPm0tWAFV9RlulVzAKEWUIB_gm_.AeC5a85rB6wo7h4lhxGL.cEMpgkYOdlG ypgnj2rZzs8.Xqi5n21tB5JVuNosI4BTtSQUjjoF_dDSXU3ftZer8kL0zIartFzEgGIcAT8WUmbG LKkGwLxuVXlu7Tg.oX.QTAifuoGFD1IHm5nVI5VellB.XBGUuL2yzO9RaegdjKrFRixMZW6JcNCc zPb4AdqS_gG2YEZaUDJ9YThnkXBALbD7dwEoFFjfPKVg0I6OOs9QjoG2y5EeXX_e8GjAThtKNI2q 0vBGMWQbPq9VX3w.kOl7NRs6QmBckim4wTZJT4qdEH5mGujf4aXfgebwn26uv3LbiI0o4R88w7pr Ri.BI._Zok7ndLgopyuoqaOLu9MUp27iYQ_I0L2ZimDQr4uXmyCUSqeRpvohCDyRzpJal4SaAsNw HMZyQw.xIsLOiZF.sjQ9PgFRrwVz_Z05MMf0gOOV94x5dCs_lfndbcJDWFTDcJoj0GfXRslMtj1P 4GgPHDG3RnRyqXG4Acw6Kkc4ARsinJutq023h3jkyy83r1yRR12rlcsqk4ff_e21yCsGq4oKc9wR 2HO6BUlTR9_tBg6KtSHUz8KyGYI_PnqfvtaxiYpRBZQtUlWS9r8GjIxApTwXKMYoqzjTcPGrhFhW BM.YJwd3ya7Jp75BN.SvgW0v0LkmJ.J_iF0KpyAJS5zifzFdxzOL_njZ.ZGHsGWN5_VGzzCcu.xJ 3huvzPllIHusEQqh9MMWpiepMn_U95Skl72L82PZo6iQtF.4U0peoTqH7f2NVH.SVvrD8wIX40F5 ZbOjDZKhPsLuk1a4bCHJWWv4zSQ4qjuvO.p6JlE04SVMQo1GPj_AUbuVjVwP3BS18P0Dp3XJdEnV HhVxZkoJHdJ4vJhK4k6MoKBHgBMv3CIunxdfxJo_g0px2VJ0a.YBgI0bFnuSCtcNVSPNnyzWPX4s HSCYrQx7jz8KYzRMRLK57IE2sJG3cYN7ybwfvt6lNX1jdZ_ejr_bgr8j.OAufVyOUBS9yG8OHU1W I9HG3GQWSMxDczUMBsO8HOhrK69RMgrEagOfB9Z.NClX4us2v165TsuQz67vD4WZEr.E_QZergDg - X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Tue, 17 Aug 2021 00:46:16 +0000 Received: by kubenode514.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID fa0259ab8f224f541284fdb7e1125ec8; Tue, 17 Aug 2021 00:46:13 +0000 (UTC) Date: Tue, 17 Aug 2021 02:45:51 +0200 From: Ergus Message-ID: <20210817004551.25qheo6v2gfys3ie@Ergus> References: <20210726165610.7pjiyuz4vtxuhgq7.ref@Ergus> <20210726165610.7pjiyuz4vtxuhgq7@Ergus> <14a3d5a3-33bf-cc82-d144-7302629aa33b@yandex.ru> <73afb142-38f4-9e0e-ee46-14ff70db5b72@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <73afb142-38f4-9e0e-ee46-14ff70db5b72@yandex.ru> X-Mailer: WebService/1.1.18850 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Content-Length: 2903 X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Aug 09, 2021 at 03:59:55AM +0300, Dmitry Gutov wrote: >Hi again, > >On 27.07.2021 02:04, Dmitry Gutov wrote: > >Sorry for the long wait, this feature ties into another old >discussion, and I wasn't sure how to proceed best. > >Anyway, here's a patch to try (attached). It should recover >performance lost back in 4ca13d98c9e while retaining flexibility (and >even adding more). > >There are still less than optimal places there (e.g. >file-in-directory-p is not very fast), and the modules list is read >from the disk every time, so some further optimization should be >possible. > >But first please try this version. Thanks Dmitry: This patch reduced the C-x p b time to just a few (~5) seconds when I have like 20 remote buffers. At the moment I haven't have time to stress it a bit more, but it improves the situation significantly compared to the previous situation. In my opinion this is a good improvement and may be installed on master, but probably it is not enough. I made a manual fast profiling and I see that most of the time in project-buffers actually goes to tramp-sh-file-name-handler. 207 42% - project-buffers 207 42% - apply 207 42% - # 200 40% - file-in-directory-p 200 40% - tramp-file-name-handler 197 40% - apply 197 40% - tramp-sh-file-name-handler 197 40% - tramp-handle-file-in-directory-p 183 37% - tramp-run-real-handler 183 37% - file-in-directory-p 124 25% - file-equal-p 124 25% - tramp-file-name-handler 121 24% - apply 121 24% - tramp-sh-file-name-handler 121 24% - tramp-handle-file-equal-p 85 17% - tramp-run-real-handler 85 17% - file-equal-p 52 10% - file-truename 52 10% - tramp-file-name-handler 41 8% - apply 41 8% - tramp-sh-file-name-handler 41 8% - tramp-sh-handle-file-truename 28 5% + file-remote-p 10 2% + file-local-name 3 0% + file-name-as-directory It goes specifically to file-in-directory-p as you said. So maybe the improvement there may be also desirable if the difference after the optimization can reduce the time for file-in-directory-p (or the caller) at least to the half. So, very thanks again. Ergus. From unknown Sat Jun 21 03:29:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#49264: 28.0.50; project.el+tramp performance issue Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 19 Aug 2021 01:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49264 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ergus Cc: 49264@debbugs.gnu.org Received: via spool by 49264-submit@debbugs.gnu.org id=B49264.162933597325739 (code B ref 49264); Thu, 19 Aug 2021 01:20:02 +0000 Received: (at 49264) by debbugs.gnu.org; 19 Aug 2021 01:19:33 +0000 Received: from localhost ([127.0.0.1]:57798 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGWiT-0006h4-Db for submit@debbugs.gnu.org; Wed, 18 Aug 2021 21:19:33 -0400 Received: from mail-wr1-f44.google.com ([209.85.221.44]:33642) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGWiP-0006go-7U for 49264@debbugs.gnu.org; Wed, 18 Aug 2021 21:19:33 -0400 Received: by mail-wr1-f44.google.com with SMTP id r7so6405800wrs.0 for <49264@debbugs.gnu.org>; Wed, 18 Aug 2021 18:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=sXRUEwQcPhVBBIRNBdGs3lHSTG0MeKma/LYTyMTAXpI=; b=fMSTN2h0/aKcO7GJ3SE6fnH8Dqm/fFeSkgd3/ZqTdTmVIHi0tum51l4hP5546/tsdR BzQtjgen/VdYmFvJKqWVhsTK7rfqmjiu6QYgFqH8bkWO30+DG1TNzHyC2a2HU4K1XwBZ MCPRqGR0M5tBF9ob7FVyOLFotgbh3mFtd9W6odakfxobeDWOBbMCEhAgYYfK1nPz5s83 SH3y47Yxo5Hk9Fhcozl6OQOTs63gQQc5dsHtfBLWsrDyrdw9ipob8BN5HRyil+FyEQl1 PENkxc1Wc4ic8rdGGKhSPZ55oqhf4DeaAVrvmT7YiYcpqUTONi5I5JJONdd1DflRmtOl vrHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=sXRUEwQcPhVBBIRNBdGs3lHSTG0MeKma/LYTyMTAXpI=; b=j7XclmOdos6+59+iln+OY8sB/F4vLkt2N5KJhKeoJueV0osDWRBxHzDIzOoNnd3kkq a/VqriCDXXIsFybuU7+IDm07SRxLIrtLiVMJzkRE839fhVvKIsTafXO7UYTPRPh/+fPK Lz11WkOEFdTfmu/XaCg+sCkutOpYY0ok92U+s1hPcE8slmFH40GvkbIok+fq5tRau2c1 an4wJVmmFHoyKhwNQwTAFMNkNZPu4Sv7Exky6bQIxGsUzF+NM1aZrEzBL5RGt8WGdYIB itTJ+G9DCjrgQWtNbo2/O5AdIdr8ARbGIz1pVx4KD/gHYXssVUdf32dpOnvjXBnsZk62 OTFQ== X-Gm-Message-State: AOAM530FbotGW/JDlRQJt6SbjQjEA84Pq1+Nb88hjYHeaU2BoB14SCTz 5MrQ3p4oVe24OlFtkz/T8T+n97vXzfk= X-Google-Smtp-Source: ABdhPJx1fuaIuz7cvt5UOyS4KywKATyeYangnTEMUV37WH5vjVN23Y0evqfEU6DbKjxIOsGZIHK8/g== X-Received: by 2002:a5d:6301:: with SMTP id i1mr380377wru.423.1629335963211; Wed, 18 Aug 2021 18:19:23 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id s141sm1123822wme.6.2021.08.18.18.19.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Aug 2021 18:19:22 -0700 (PDT) References: <20210726165610.7pjiyuz4vtxuhgq7.ref@Ergus> <20210726165610.7pjiyuz4vtxuhgq7@Ergus> <14a3d5a3-33bf-cc82-d144-7302629aa33b@yandex.ru> <73afb142-38f4-9e0e-ee46-14ff70db5b72@yandex.ru> <20210817004551.25qheo6v2gfys3ie@Ergus> From: Dmitry Gutov Message-ID: Date: Thu, 19 Aug 2021 04:19:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210817004551.25qheo6v2gfys3ie@Ergus> Content-Type: multipart/mixed; boundary="------------C682CBA70B2A03444050029C" Content-Language: en-US X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) This is a multi-part message in MIME format. --------------C682CBA70B2A03444050029C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Ergus, On 17.08.2021 03:45, Ergus wrote: > I made a manual fast profiling and I see that most of the time in > project-buffers actually goes to tramp-sh-file-name-handler. > >          207  42%         - project-buffers >          207  42%          - apply >          207  42%           - # >          200  40%            - file-in-directory-p >          200  40%             - tramp-file-name-handler >          197  40%              - apply >          197  40%               - tramp-sh-file-name-handler >          197  40%                - tramp-handle-file-in-directory-p >          183  37%                 - tramp-run-real-handler >          183  37%                  - file-in-directory-p >          124  25%                   - file-equal-p >          124  25%                    - tramp-file-name-handler >          121  24%                     - apply >          121  24%                      - tramp-sh-file-name-handler >          121  24%                       - tramp-handle-file-equal-p >           85  17%                        - tramp-run-real-handler >           85  17%                         - file-equal-p >           52  10%                          - file-truename >           52  10%                           - tramp-file-name-handler >           41   8%                            - apply >           41   8%                             - tramp-sh-file-name-handler >           41   8%                              - > tramp-sh-handle-file-truename >           28   5%                               + file-remote-p >           10   2%                               + file-local-name >            3   0%                               + file-name-as-directory > > It goes specifically to file-in-directory-p as you said. So maybe the > improvement there may be also desirable if the difference after the > optimization can reduce the time for file-in-directory-p (or the caller) > at least to the half. Thanks for testing. Try the attached new version please. It should eliminate that particular bottleneck. --------------C682CBA70B2A03444050029C Content-Type: text/x-patch; charset=UTF-8; name="project-buffers.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="project-buffers.diff" diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index 4620ea8f47..f9b302bb2b 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -51,6 +51,11 @@ ;; files and its relations to external directories. `project-files' ;; should be consistent with `project-ignores'. ;; +;; `project-buffers' can be overridden if the project has some unusual +;; shape (e.g. it contains files residing outside of its root, or some +;; files inside the root must not be considered a part of it). It +;; should be consistent with `project-files'. +;; ;; This list can change in future versions. ;; ;; VC project: @@ -334,6 +339,16 @@ project--remote-file-names (concat remote-id file)) local-files)))) +(cl-defgeneric project-buffers (project) + "Return the list of all live buffers that belong to PROJECT." + (let ((root (expand-file-name (file-name-as-directory (project-root project)))) + bufs) + (dolist (buf (buffer-list)) + (when (string-prefix-p root (expand-file-name + (buffer-local-value 'default-directory buf))) + (push buf bufs))) + (nreverse bufs))) + (defgroup project-vc nil "Project implementation based on the VC package." :version "25.1" @@ -628,6 +643,23 @@ project--value-in-dir (hack-dir-local-variables-non-file-buffer)) (symbol-value var))) +(cl-defmethod project-buffers ((project (head vc))) + (let* ((root (expand-file-name (file-name-as-directory (project-root project)))) + (modules (unless (or (project--vc-merge-submodules-p root) + (project--submodule-p root)) + (mapcar + (lambda (m) (format "%s%s/" root m)) + (project--git-submodules)))) + dd + bufs) + (dolist (buf (buffer-list)) + (setq dd (expand-file-name (buffer-local-value 'default-directory buf))) + (when (and (string-prefix-p root dd) + (not (cl-find-if (lambda (module) (string-prefix-p module dd)) + modules))) + (push buf bufs))) + (nreverse bufs))) + ;;; Project commands @@ -1014,13 +1046,11 @@ project--read-project-buffer (current-buffer (current-buffer)) (other-buffer (other-buffer current-buffer)) (other-name (buffer-name other-buffer)) + (buffers (project-buffers pr)) (predicate (lambda (buffer) ;; BUFFER is an entry (BUF-NAME . BUF-OBJ) of Vbuffer_alist. - (and (cdr buffer) - (equal pr - (with-current-buffer (cdr buffer) - (project-current))))))) + (memq (cdr buffer) buffers)))) (read-buffer "Switch to buffer: " (when (funcall predicate (cons other-name other-buffer)) @@ -1160,7 +1190,7 @@ project--buffers-to-kill What buffers should or should not be killed is described in `project-kill-buffer-conditions'." (let (bufs) - (dolist (buf (project--buffer-list pr)) + (dolist (buf (project-buffers pr)) (when (project--kill-buffer-check buf project-kill-buffer-conditions) (push buf bufs))) bufs)) --------------C682CBA70B2A03444050029C-- From unknown Sat Jun 21 03:29:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#49264: 28.0.50; project.el+tramp performance issue Resent-From: Ergus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 19 Aug 2021 03:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49264 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 49264@debbugs.gnu.org Received: via spool by 49264-submit@debbugs.gnu.org id=B49264.162934255311692 (code B ref 49264); Thu, 19 Aug 2021 03:10:02 +0000 Received: (at 49264) by debbugs.gnu.org; 19 Aug 2021 03:09:13 +0000 Received: from localhost ([127.0.0.1]:57878 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGYQa-00032W-Rc for submit@debbugs.gnu.org; Wed, 18 Aug 2021 23:09:13 -0400 Received: from sonic313-15.consmr.mail.bf2.yahoo.com ([74.6.133.125]:33388) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mGYQU-00031s-1k for 49264@debbugs.gnu.org; Wed, 18 Aug 2021 23:09:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1629342539; bh=vSPcNxQhDGZ/JGO2hGm89c5fp7r3Q9iDeX4/LuYs9IM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject:Reply-To; b=RiKUqfP/CzUQ8uLFC38I+l8FzOSIf2epwFpCEMXe477uiz68TMzOiCSKaDyE9ZPM/M6+eI73ViGuX6DRb7xMPoSknmnsmAdFmrT3jLDnkEmvrFk62qflLcw4zH1nfjl+05iEFCRIrdSgDF0zwOY5g8vHK/gjEQoYxZT6bg+aD8ueoJgtP8J/kuSs5KBahj/tY//4usI7N+xfZB3nW9IDilK6H7QZX/6673CR/G5ZxKNwmG60GXVPuY7GxqJQDaMzHAbFfb7qpC/mMPORiSZVv4UcEqKlFBb/tNh6RdSt5RNg87oerln4vRTKEVJ11YLcoY7v6s33lW7IPyPXdHrC5Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1629342539; bh=nWqc1K816kPqYbp+bwRmT6Mi6AYXcQPn/3U5RRKhFqW=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=kek21LOfpVLCIB64ILpr+HtFQF0lrJXytr1QWUvXYMtnIjDpTW4ew3KwvYbR2bbK/QSz5oTTDlGYjD/FjY9JDlf6HBIqtdvfhoCQ9FV4XioymTjtkb/XxHhbZBwIMtdSHlNpMe4mKLKMVJpqze4EAi8mAVxkFl7JtQKFTBbVPSEPbSkjlF605U5TB2fvO+AgwHFC2EN80XB+QKuOlCSGocLPbgpkFm5y720iX4+7WdPJNotBV4hdAEoWqPxScQ+00k8WTIXbv7vEaDF9zClBdMkLMx681zeYQOOcVwaSko4JTHpEQTUvXcsahsIu/q1JUoS8WZPrW2vNhVu+0FD9HA== X-YMail-OSG: q.Ot9cIVM1meBs_BgWSl1il91GUzUVNLD5tterWGFY9eOYayAxxd6xPmK1Y4bxx ZR02nVAaEN7A_tZ09nO48h3Ji55lwyBW7oz221HgaEG4zCvYNeqOJzdGnzSF9aXCu54j7NuzCshg nPNjs0MLT1DkC7yjBvZRtge_Qax7O9ymSQ4jRGoMxBVsJYSWTAATt0ahIOcRDL42P.YY7XDlZWwh ukq8IS40T3HMwXe1yJY5sjrCQcu9BIwuiRtZX81ie30lakERQudjg.2DIBpeDupFM5lmZyIXaZN1 pERNRlZYJpXxTPsMYAABgtCqEGuzN1Z1QCtk_skwc3OVuM6GnUrAVaaFpUMTLg2RyA1IqcD.qiEB aknWwx9p41urg4Mm4nGVw.bXLm8ZEZI2j4MTOtjO19OjSvvh9l6Fh6wxuuLZ3fguXxx.fZL8a.gF jMdZqawJ1bcU.8xTvCNbl69Qk9pjbdjIgjrZiAXoScSQNIkbwtH8bAbYpax0EGoGxZeJYOkwFZBx iLzt9ci6ZDz00BhoxlKsy0W_96sQMRh8dpGxmwCYcVswWuK1tmLhcLyQGRM_BgRrp2qwVaNcu5ev kB37R_9Y6.vJBYtzNU7.coafb26w..ifXZXF4F4rJZkaZNRx6x6f1z30vtJhzvmhnb8gknpJqQkQ 7dIQkv7IjR_aDJSTl50uJgbrd9W0X9vsWtTCX13WjESaGLapxKZmRprORrgh7O3gMvGXAinEhv6E fETYxDSRq78KRKeYrM210x1Kj_pDL9hpE.gv2MkTY8JEcGRZKG0eQOTiRGy_qRBsY6znRWjSysW3 ZPWIq7tWClY3hfQBInx5HqcabK7_ScI8mUpwkXfI9iEmMUYfgkliRriC35JjwgK8hVOjiQqovb9. yvwkgPb902nKthwxApM6buQHz4GnLWJ2QUcLfYlgR2xL0nhB1sDVX01rvPRTwPVADKe8ikubdp7b r4zoAdzFnbwnK3wf_Xm.a1DzA.fBbGB7IdkahmpFnqWlXdwvDZycG6zuXWUzSjayj3q5bDpvy3q9 Sr7OK07jKA2G3FFYWUdxHb_e9zHQAZSDSHp5vSH074ZFNq_JoiTuv_4DBoX3rXdEsuSE2yBtDJjW m9sc6D5rJ67O04B2vZN4nfG5GYkkZ7jWzAqFQk6jrNOmHeK1ppj1__Zsik3OgOySjVO4LeH5YG7A R9RIeGCMLrL1cZMdeD.DaAs0RG8Nv_z9J.3wNwzS_dTiAPfHD6iG3T2tSgKQlpab86ICqoabdnsO bI_tsPjCke_IaUio_p9nBB48dMxZQaC_0E_37orBiq8WfzwjWmN1aJu_BQYlXWs7jhpL7BRZFFds xzwOMABlSHoeyTwT0qwSq3XbTMbSi2T8BmoBUvL3oxHoRsCvndb5TddhjHTZaL1oNWcZKNNYWj2Z t6dpVjdPrOTL35INq.Y7pXNaIPU4Xy4dqJBdLAwFef64bG4VkopyJSv_R35Qx91jNZA8K7h9ux3_ dQ36v_PrzkbXFRvlIYkCQajS11hy_.QwWgI9bAXXn9aANLDsR65zTgijJh0JmkYzzY7jC.H6suJu mCfGBNxj0Hs08mXmEcwBh8r8Wr9lj4Ow85DnMTn0WX0LOb2WyjZ9D.dClqhEMy8MyKHxXsh1u8im Zs9JvraLeHCTbLvdyYQ8a4IHX2.katmVNmi5MGXF0shtn657tFaVyqovue29jCtlQRtH51I2JPAv 06ju6bTD8o5J4k8hgAeo1Sve4dFd7L.GLwJ2j.I3qzsrIcIpsn8RoNMHXLZSY.p5.sZORrh0dl35 VAUxlOaOoOvvL91pBypkTSor4iyA5LSAU4U0lBB3YMzCVHmaV7ggv5bJDjxXDCMr3PQm2RFAhxT0 MpHMmIUSzMFBdXSeSLTCmTmUAqLX6ZF.jkLpDFbonKZ_6sg5Rb3A__yBe_eTBfjuB3LhfdADBZzp nx.FgneI3xn0hPyEMMrJH8c5U4uS0Qs5.0wZtbc02Rb1IFhiMOUjB00vCmyOtqLTvaPnuJAmhx_h sJk964xcM8tqcmkB._UThsjvlvpyOQqYzAxvbHegpQHXfbqJYlu.KDzYaLaUptk0ncOniwzjdzFj ubU9Vs0CHmxoP25rqm04oeGxVobcRUXnoRhoVlxgpDNMLsXF5e9IKu2zGYEUfUqz1MvnsRHv40bT u_iaSKUbLteoNuJrb8mpjmBW8l15lZiS2TzsCukS4v.a5P6tEebYHr85Glpnn.6a3wTHDTOcv_id E0J7kvgifmzGxg24yYORFUxGzgIe_J5YRF1jml8eEIlAkUrLF4E26J..T0wJ5OmUFkQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Thu, 19 Aug 2021 03:08:59 +0000 Received: by kubenode527.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f3336c55d69bb0c628feb764f49b83b5; Thu, 19 Aug 2021 03:08:56 +0000 (UTC) Date: Thu, 19 Aug 2021 05:08:33 +0200 From: Ergus Message-ID: <20210819030833.b5xejdgjy2avnq2e@Ergus> References: <20210726165610.7pjiyuz4vtxuhgq7.ref@Ergus> <20210726165610.7pjiyuz4vtxuhgq7@Ergus> <14a3d5a3-33bf-cc82-d144-7302629aa33b@yandex.ru> <73afb142-38f4-9e0e-ee46-14ff70db5b72@yandex.ru> <20210817004551.25qheo6v2gfys3ie@Ergus> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Mailer: WebService/1.1.18850 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Content-Length: 3857 X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, Aug 19, 2021 at 04:19:20AM +0300, Dmitry Gutov wrote: >Hi Ergus, > >On 17.08.2021 03:45, Ergus wrote: > >>I made a manual fast profiling and I see that most of the time in >>project-buffers actually goes to tramp-sh-file-name-handler. >> >> �������� 207� 42%�������� - project-buffers >> �������� 207� 42%��������� - apply >> �������� 207� 42%���������� - # >> �������� 200� 40%����������� - file-in-directory-p >> �������� 200� 40%������������ - tramp-file-name-handler >> �������� 197� 40%������������� - apply >> �������� 197� 40%�������������� - tramp-sh-file-name-handler >> �������� 197� 40%��������������� - tramp-handle-file-in-directory-p >> �������� 183� 37%���������������� - tramp-run-real-handler >> �������� 183� 37%����������������� - file-in-directory-p >> �������� 124� 25%������������������ - file-equal-p >> �������� 124� 25%������������������� - tramp-file-name-handler >> �������� 121� 24%�������������������� - apply >> �������� 121� 24%��������������������� - tramp-sh-file-name-handler >> �������� 121� 24%���������������������� - tramp-handle-file-equal-p >> ��������� 85� 17%����������������������� - tramp-run-real-handler >> ��������� 85� 17%������������������������ - file-equal-p >> ��������� 52� 10%������������������������� - file-truename >> ��������� 52� 10%�������������������������� - tramp-file-name-handler >> ��������� 41�� 8%��������������������������� - apply >> ��������� 41�� 8%���������������������������� - tramp-sh-file-name-handler >> ��������� 41�� 8%����������������������������� - >>tramp-sh-handle-file-truename >> ��������� 28�� 5%������������������������������ + file-remote-p >> ��������� 10�� 2%������������������������������ + file-local-name >> ���������� 3�� 0%������������������������������ + file-name-as-directory >> >>It goes specifically to file-in-directory-p as you said. So maybe the >>improvement there may be also desirable if the difference after the >>optimization can reduce the time for file-in-directory-p (or the caller) >>at least to the half. > >Thanks for testing. > >Try the attached new version please. It should eliminate that >particular bottleneck. Hi: It feels better now. There is still a small delay, but that is normal working with tramp. I will try it a bit more tomorrow; but the first impression is that this solves the issue for me. Best, Ergus From unknown Sat Jun 21 03:29:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#49264: 28.0.50; project.el+tramp performance issue Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 21 Aug 2021 02:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49264 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ergus Cc: 49264@debbugs.gnu.org Received: via spool by 49264-submit@debbugs.gnu.org id=B49264.162951259931648 (code B ref 49264); Sat, 21 Aug 2021 02:24:02 +0000 Received: (at 49264) by debbugs.gnu.org; 21 Aug 2021 02:23:19 +0000 Received: from localhost ([127.0.0.1]:35714 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mHGfG-0008EO-Oo for submit@debbugs.gnu.org; Fri, 20 Aug 2021 22:23:18 -0400 Received: from mail-wm1-f48.google.com ([209.85.128.48]:39762) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mHGfF-0008EB-42 for 49264@debbugs.gnu.org; Fri, 20 Aug 2021 22:23:18 -0400 Received: by mail-wm1-f48.google.com with SMTP id f9-20020a05600c1549b029025b0f5d8c6cso10190823wmg.4 for <49264@debbugs.gnu.org>; Fri, 20 Aug 2021 19:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=LJU6XpWzgCeyc0QGrJ6P2bEPN2ZKTdXtybOupTmtNv0=; b=pnz84/ybk08Lc+HcnoRrzR7457KV/yndMEqf0wBUerqf+6hcT+uXrdP09DsFxj1/7T 6QhtTiQxFiyW57bMlZifgN1eWG+y26oERgwOpmqijtQ1eQWqqZ7oRHYmiEiooIqhtKKP MFDowWwhXMDMCdqq5+eCm4AjVDkh8q+ezJT8cqoyjuQyUKoxf3Ap/4MQAgYsbcIvHXmd uUDYHnqLYTI1PpKILrAUNleeD7FgSkTMpLVzBAxAoK9OVEW/GBhMNGSI/VDdWcoNBeCu Bo7O1wVC0eX532m//X39PXkIQf1viG/AZ9UWh4tEmWtGsFLumOkmrGlZwaRyGqjle785 WkjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=LJU6XpWzgCeyc0QGrJ6P2bEPN2ZKTdXtybOupTmtNv0=; b=hLS+BJYpnXuopKpDQtp2FbT+8q1N6PgVZGdz5JIarmQUJM5zCuxabqlmT4HG2s4r4N MoTYKYzT42AlRefEVIJb6tZ3esJUZfzm5zUglxmk/TOvUZkbToeEazkkY1nAVQj0tLsb FuWzmJp9XGy2Psd9vYK9k4Zz7wxln9CBdDS3rg8CZ2lN6BK6oJl3rImMEDw0kQzKlpDA KNUr4Dcwy1wiNaxflDwexAJcKw8IuLwahgpksTtNS1EeM+0L87AuYBY+L0Yrr0S/TbuM r5j3r5BPULTODBtuktvf/+W+SjInVXCXd1id4yJ/V+b8gWUc7CScwdD4ybOZl7CMGUnU nHQA== X-Gm-Message-State: AOAM533m7qqKZ6FT8w7TVZ0t4S9bS6DUxBwhCr7LKve1FOvkaDcHnTlY zZiBhc7VyrQI7cdEFTzF0nkLQgiA2bc= X-Google-Smtp-Source: ABdhPJyRxbSP7yctcKXnbWzlmOFDUbqkAioiPVuqll06/5WHzRVEGcWnCgt2MogqnsCq9FUW269B/Q== X-Received: by 2002:a05:600c:4111:: with SMTP id j17mr5436371wmi.167.1629512591314; Fri, 20 Aug 2021 19:23:11 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id h6sm7486329wmq.5.2021.08.20.19.23.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Aug 2021 19:23:10 -0700 (PDT) References: <20210726165610.7pjiyuz4vtxuhgq7.ref@Ergus> <20210726165610.7pjiyuz4vtxuhgq7@Ergus> <14a3d5a3-33bf-cc82-d144-7302629aa33b@yandex.ru> <73afb142-38f4-9e0e-ee46-14ff70db5b72@yandex.ru> <20210817004551.25qheo6v2gfys3ie@Ergus> <20210819030833.b5xejdgjy2avnq2e@Ergus> From: Dmitry Gutov Message-ID: <9d90da7b-7bd7-7096-e0c4-e2ae8e30a883@yandex.ru> Date: Sat, 21 Aug 2021 05:23:09 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210819030833.b5xejdgjy2avnq2e@Ergus> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 19.08.2021 06:08, Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: > It feels better now. There is still a small delay, but that is normal > working with tramp. I will try it a bit more tomorrow; but the first > impression is that this solves the issue for me. It does spend time in reading files up the directory (in project--vc-merge-submodules-p), though I hope those are cached by Tramp. And then, if project-vc-merge-submodules is set, also reads the contents of .gitmodules. But it's probably not the case. I'll push the patch now since it seems like a solid improvement either way. Let me know if there's anything to be done here, or we can close the bug. From unknown Sat Jun 21 03:29:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#49264: 28.0.50; project.el+tramp performance issue Resent-From: Ergus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 21 Aug 2021 05:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49264 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 49264@debbugs.gnu.org Received: via spool by 49264-submit@debbugs.gnu.org id=B49264.162952466918245 (code B ref 49264); Sat, 21 Aug 2021 05:45:02 +0000 Received: (at 49264) by debbugs.gnu.org; 21 Aug 2021 05:44:29 +0000 Received: from localhost ([127.0.0.1]:35760 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mHJnx-0004kD-D9 for submit@debbugs.gnu.org; Sat, 21 Aug 2021 01:44:29 -0400 Received: from sonic310-15.consmr.mail.bf2.yahoo.com ([74.6.135.125]:44145) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mHJnv-0004jx-Bn for 49264@debbugs.gnu.org; Sat, 21 Aug 2021 01:44:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1629524659; bh=asAws3rK5YjtrXa26CrrvwbhFRPkzm9nzS3rwB3TDyQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject:Reply-To; b=VlKIUDl7ydTflUGCvqFGLYkuAovvYrzkffYn7xgTiCqV88xd1FKQcuVX0VChyvt0TPCBZigN0hxVjdvJQtPSJwJd0vPH2KYMLTQoQaFJvj4rxmXXuVEi9KU1U8IS3G1rSvbVcvYA6JKxpO9kvXYeXmLgpCDsTanzWK/59kVbnjhq1O3bS1VpCRcL7j44xqfwQmXjiGEhLiAlmh1gKI8qkqGpVoZzguKr/VSmRDeTLWgQ5Dy4L6N5jxEDGOnzvCZDZVpJt+1Uet5rkbVAyB7Ud1kpRNFV6lYwsdO1arBjWz1X5IBis5O72CA6oliAqZbBzxfWS2/iHn3d26YMUHTtJQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1629524659; bh=c5feD9cBsC/8gw3TJgiVi3h8baHH5+8lU/ZPeHTKHK/=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=qS8E9kZpJOOhZszo+MaLnA7OTq9n/dqbdfyMp+BNOHaqmfCNQhYGV91KFJYxHvqnq7SXMNPM952X+Tyj/JJw36TkK1HucoYUgIDCbroffNUkfR0v+OykYzZlrScn3Hv49En9lVmp8JZCFrH04bgoub3X448devxpBhDh8aZjvo3xijz/3JwoqXTOZMufhvocWlYPrN+Z2v5OT8hUMruvtOwr/F4BV8vrFdYFNPzEU+zDwfruerp8+WEa08gcZlAzLD6PRdRNTYIjheNqFUURb5HzSDCR9yxFS/Ut9Lp90A3fFqHcwSNIyVvdlwJdwDzTPol7U8ls/LfWQKkkHirX9g== X-YMail-OSG: R2KqqfgVM1ml4WxjnyByfTbH18czCgH9y_Jv5F0w2gwful50tCOr7kZIkN5fMjs xaGMBkU1C3irBKjsmf8eRhr8sZrRpNH4atUIondoDpkaqKe0iWMTCPp45UX.Glr5sQiDKt6Bx560 dqCFMMJ2q.FfLH6xBXUOvPmthg8M1q0k8GsHX2f3TLDuClGFmA1y7TTieDBgzjNKQzaaQd9KQctL PmxS6zAx9TxBJWHUe6iBwBjF.d8rtub6ACnTE7.pcyalOSnf_DMyYuCaxrV2l5X4jDCA0jiDiXsW Cf1nQSRQp.yYrGzc16axNQKAhXAHRS01I_LmPdzTF1l_Wjab2f80uizuVO21YGEWJBQgHZvbSl7r VyGAmwVavDsiSCzEzBVg8avhiOzEOwrxbD4K0bjHx5bECGHa3AjyN0pfvBPvPQ.okIdDARX1_0bQ n363Ix_KwX7Y1XMWRUXUm9lEvcFcurk5iQgHaTPO17CKy6w4QR5260AA0aSyI2ItWGJeiecKvuqC sgiRhrK6eeZUp_IpVSab2GThsO4ucXTIIURdxkAaGOq6247.KVwZoERChahDnJej8wwVNL_InciN JPYaMJhFaQ6yDZmGUXwjEB6oWqm4WlJtMPrTn0uCdQDlWh3g8wHAEyYqnmWtBhM0OdwlCfou.0t5 GCF24PFdAujSmv6m7j02XRHdqEqLay7IAEbrw1sz1i7C5uUOZYRDrYEipSpL_d6fXriVjgoOB.V5 edukqG5IPL.nHsR_pjq3BiK_8hjMfBwd3CmApQrvKMzViY1HsqrPztZEavNTCAbljGlMss.lKt4r z9iXB2EdnizvbI6W_WvK8ElEoFA.JhIMcGYiUZ.1U_htZAX5EwcFIp7kB4ALQLnTJyTm1putkEjc Y6vrxk0SWi4BcZ03G3DuFrlXEVGSRlKG5797a3FvFJS52fpC_l1MbDP36VBZq7B2HViIMWEE3c2P 1ol551ZxUUQdpiG7uLzSL34LQhcwFbUmpBP7rumdQlMLMX8zV3d98WcAIh_OiVpccA3lDzaBEz7P JJfyVc4PcdUetjFTikeza6hGDREUTKS4jcYpKQ6J6PAdt2dzNYanFH41YxASAL5_FSPWXzCjYls0 QipJ0uDqGKXIQQwyIvSbez7SK_lHs8BJhY0IW7ipFuyNGF3Ur9upW.XbWhZZLyKj9ZVtR5qrEQ.k 0mMBYiOJYqXKuyxYEfFPee5bi1jozkScjwwr2GIXhA5HjEOPTE_tBsHB10zBv8tWBjICvQ7GdX7Y 28Y2_IeEJnw_MCKkvy6aYYPeYARXhqhA7dclIy4VR7YYSVgjXbWQi1CvFwRtXfSmztK3HAgDL4u2 myBJlFrs19chfD7qPQH6OSVHBl5CobWKNtj.qIw3nLrJBTlWKjL61nW0NX4A50shHxtN9pX7RWKV 2hpK23v.QWSPIhK3kpQOCF_t519OGvcqamW9Nq1MobEniofsU7CQ_RV7CCsIXF_HRu2xC.BW2OlC BCZf_G5roY7wBjWJnRrvNxFdmKyHhDwLgqSL44R6V8AYxOjuMMEduYjQY9WjbjLy3pxalkp2dbx3 Lnutbc3z9_zEfhFiIJ4QB3BcnYgx_qsbzgpajmE4hTBjm8IzNrVC1KZx7MQ6EedW4gc7MC2KzXcL 4XNL.W3xwg2N0O_Tn8cH4RQ1lbZ2MrsM0.VXxek.EnQguSaTDISiqG_mhcu.OgUZcVQzE_cD53bO CZJYcVUzPzS_86JbO89.yvd8fclA1WdqeSow5ZJFf6rYMd6GzdqYv6YnZVcKOH0AqLBO.1RiceOG bLDFOyVxI.qp_9OoBo6ywdL.iKgyE01K8lZuJxGns_Llja5g.f1fRKce7LzIeTcVp3JvGPIht7_s 7OYLdYz4Fqm0E9JUDsjwWRZyC16mH9JtAmPEdBkJuDh8ejtF3BqsnnbGZP0qbbc_iwN7W4bx16ES ICCl_MBTvg0gDb0t4zs3mrrIAAJaiw0.C3BBzRG2kipLmgzvMBrbKN6Cph1XB51HtvHQeY.sXrRb 3XKT3Kwn8a9MDTLZ.khIY2TQ..oTD9cw_gcyVUk5.UX30ksU0fapxEomKHqtRg0YPQAY4.y1VMPq dYJyTQtoPJaXC9OlB0wTznNBYaR2sWUSXgB3Mk9a.4HDEfmkMfJpkGw9jHDA5raTqHhY.mfxOa2q _3c3tYLyH3LetF_k5K2nXT0UgZIBUXsaxy4_2_VUuseXF.AC4Dn5vNdxV3zMF0vutDxr2uLZG5KO ikQHaI.yrS6Bhajvx5bmPhLvCMR8uGTvd4srPyQEWhHM53_JChh7sJ2jCihrVbyI- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Sat, 21 Aug 2021 05:44:19 +0000 Received: by kubenode524.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 5ba170bec962a6fb879d8c3fade517c3; Sat, 21 Aug 2021 05:44:15 +0000 (UTC) Date: Sat, 21 Aug 2021 07:43:51 +0200 From: Ergus Message-ID: <875yvz1hfm.fsf@aol.com> References: <20210726165610.7pjiyuz4vtxuhgq7.ref@Ergus> <20210726165610.7pjiyuz4vtxuhgq7@Ergus> <14a3d5a3-33bf-cc82-d144-7302629aa33b@yandex.ru> <73afb142-38f4-9e0e-ee46-14ff70db5b72@yandex.ru> <20210817004551.25qheo6v2gfys3ie@Ergus> <20210819030833.b5xejdgjy2avnq2e@Ergus> <9d90da7b-7bd7-7096-e0c4-e2ae8e30a883@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <9d90da7b-7bd7-7096-e0c4-e2ae8e30a883@yandex.ru> X-Mailer: WebService/1.1.18850 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Content-Length: 907 X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, Aug 21, 2021 at 05:23:09AM +0300, Dmitry Gutov wrote: >On 19.08.2021 06:08, Ergus via Bug reports for GNU Emacs, the Swiss >army knife of text editors wrote: >>It feels better now. There is still a small delay, but that is normal >>working with tramp. I will try it a bit more tomorrow; but the first >>impression is that this solves the issue for me. > >It does spend time in reading files up the directory (in >project--vc-merge-submodules-p), though I hope those are cached by >Tramp. > >And then, if project-vc-merge-submodules is set, also reads the >contents of .gitmodules. But it's probably not the case. > >I'll push the patch now since it seems like a solid improvement either >way. Let me know if there's anything to be done here, or we can close >the bug. IMO we can close the issue. If there are still some problems then I will reopen it or create a new one. Very thanks. Ergus From unknown Sat Jun 21 03:29:22 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Ergus Subject: bug#49264: closed (Re: bug#49264: 28.0.50; project.el+tramp performance issue) Message-ID: References: <87fsx13aiz.fsf@aol.com> X-Gnu-PR-Message: they-closed 49264 X-Gnu-PR-Package: emacs Reply-To: 49264@debbugs.gnu.org Date: Sat, 21 Aug 2021 11:00:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1629543602-15317-1" This is a multi-part message in MIME format... ------------=_1629543602-15317-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #49264: 28.0.50; project.el+tramp performance issue which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 49264@debbugs.gnu.org. --=20 49264: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D49264 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1629543602-15317-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 49264-done) by debbugs.gnu.org; 21 Aug 2021 10:59:37 +0000 Received: from localhost ([127.0.0.1]:35916 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mHOiv-0003y7-EZ for submit@debbugs.gnu.org; Sat, 21 Aug 2021 06:59:37 -0400 Received: from mail-wr1-f41.google.com ([209.85.221.41]:37633) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mHOit-0003xj-JT for 49264-done@debbugs.gnu.org; Sat, 21 Aug 2021 06:59:35 -0400 Received: by mail-wr1-f41.google.com with SMTP id v10so6753577wrd.4 for <49264-done@debbugs.gnu.org>; Sat, 21 Aug 2021 03:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tBjPWKPNFPU1ft+wD9WC4X1AsGd/0qk7dTF/cy0/Q0w=; b=VcbSAXq3ga8zNZZmNI+acClPYi4Np1GYJriHcD+V3WQsHhgbJ2IYOTpEKTjEM7WclD 1S5y/YmEdDN3cmzydpe6/z12Ojz33OmS8QLJyGNVTNk4xeydqctiYl6Z8JkVIrC4mnE5 wmnfqQj6LPNiO6fxwwl7Fa/Qy0fDfOc9y6sdu7+ZRfowFKlzlZomqfrT8/qDMnB8Ohtu +LwOqvzxR80D4+Iqo3WR8K4TgdnbMXl9d3o8tDM8K3kc6BG4QUB+M65BtCoQ3nmLj9y6 hf/6dvqNLJxHepw8L8KG8/EmgBLyXYq35jyANOFXF7vPaNpZ44vb47yw3kquNEU6tXPs BGIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tBjPWKPNFPU1ft+wD9WC4X1AsGd/0qk7dTF/cy0/Q0w=; b=eJWf4IS4JFZH6tXC0HbQuMwVzd3vv/trLhBbsKYA6kVIDDbDH/BK2RWd4ygg5MvTBq 2GgZ6CZDEi+bj46uVrcZkUQajTwTSn3c1jQMsK0HHQ8khmYoeFgGqaqveVaGqE4Y6Le2 nFWXWbGarWBsqcKQ5Wyc4zxVBTpPnfrVJ35GMXB8Vla+4jynIsqQKLbxO1mbCLdVPhG2 KYdViRYbxnQDo0RSuZxndsOZCFV2PDGndZUppjgi01BknY9BDzHy4yD9w0Jsed5PAQZS XzpTJv2/7becvmVXPJPFcpnPOLs4LaskLeeQUGdVw/pfT2rN88dMeBo0lM7uAYopAkU3 ZTHg== X-Gm-Message-State: AOAM531g2c+9FqZh382YRdMMmdxy0vYG63WP0p59/kQ6PVH3dItnEsVN 1UlDYtxob6abMBdvGwa8fcZ8BCNa7K4= X-Google-Smtp-Source: ABdhPJyQ/WPu1Xsf9E2jq9lXaWVc6ZLXyqnAcE0cY3d+R2Dy9pT0AkyamVA9fe101GpZmuYAv2gSuA== X-Received: by 2002:adf:e445:: with SMTP id t5mr3393120wrm.52.1629543569654; Sat, 21 Aug 2021 03:59:29 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id t14sm12384845wmj.2.2021.08.21.03.59.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 21 Aug 2021 03:59:28 -0700 (PDT) Subject: Re: bug#49264: 28.0.50; project.el+tramp performance issue To: Ergus References: <20210726165610.7pjiyuz4vtxuhgq7.ref@Ergus> <20210726165610.7pjiyuz4vtxuhgq7@Ergus> <14a3d5a3-33bf-cc82-d144-7302629aa33b@yandex.ru> <73afb142-38f4-9e0e-ee46-14ff70db5b72@yandex.ru> <20210817004551.25qheo6v2gfys3ie@Ergus> <20210819030833.b5xejdgjy2avnq2e@Ergus> <9d90da7b-7bd7-7096-e0c4-e2ae8e30a883@yandex.ru> <875yvz1hfm.fsf@aol.com> From: Dmitry Gutov Message-ID: Date: Sat, 21 Aug 2021 13:59:27 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <875yvz1hfm.fsf@aol.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 49264-done Cc: 49264-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 21.08.2021 08:43, Ergus wrote: > IMO we can close the issue. If there are still some problems then I will > reopen it or create a new one. Thanks, closing. ------------=_1629543602-15317-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 28 Jun 2021 22:11:32 +0000 Received: from localhost ([127.0.0.1]:53227 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lxzTX-00024u-8G for submit@debbugs.gnu.org; Mon, 28 Jun 2021 18:11:31 -0400 Received: from lists.gnu.org ([209.51.188.17]:40232) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lxzTT-00024m-Op for submit@debbugs.gnu.org; Mon, 28 Jun 2021 18:11:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51574) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lxzTS-0007w9-1p for bug-gnu-emacs@gnu.org; Mon, 28 Jun 2021 18:11:27 -0400 Received: from sonic302-3.consmr.mail.bf2.yahoo.com ([74.6.135.42]:41670) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lxzTN-000887-HB for bug-gnu-emacs@gnu.org; Mon, 28 Jun 2021 18:11:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1624918279; bh=yXMBLpUkKtciNPAdYKF0xinWWVzc328j8BDTdQPc5Fg=; h=From:To:Cc:Subject:Date:References:From:Subject:Reply-To; b=fyj53isZtmkLBs/SBIJds6xb/TTHdfQlSJohVPmzIpxO1X+4jdKM29WXLpgRHC7y2t8ywvKXcyZ1O02vgJlkoTQVIhsQlmtsGC+KCg+Vg+3hkN/e1egPgJtGgStdmQuNnReSYq+Zvmh0yRVnrk8gj0HCnvrXMKunzumkGHyBq3n7yckfnbVFP3XuzyswpC0PBywSLSifYMGXbTkH5ILhvdCibwusZItX5bSrWj9NC83p9dh1Ogi8Ht+Z7zh6rAiQPTYf1sDZqaNrD3mqLtkD4HuMbdSawXVA/quG1Neb4c34kHCXXvNBIrcZHe4o4/6iNNTd6o0TFiAZed+eDQBEJA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624918279; bh=wH2frLZevEKxC6JMKP/jJVQ6D2KA+qNU9BTZIJDvhRw=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=IT2PycGsTWQvWFs4adtBuIonpY0nwKUkVWh9PFy9IC821DKe+iFb4f34ZsSFmTW6JNYT2xicLq+Xdi4kbZaw+hfAYGEZCexAvTFGfUEQcQma7wLwSP08D9AMhqcH+BEAbzRTEkNBKp6FhPUKMXUey/9aE5TPEeH2I80F9DXyZpBDJmnDDs6j7EtTDHmENXGAmlM5V+dZBzt4lqYR6NO9I+ViCn6/EJw435sUSJFXF0DvyJpgyhsm72Ex4VmtKTuNYbBKeeBB0R1zRsVHyIN7mqHck/43WAlnrW+KEeqaQq71AkkwFoJeIcvdZ9jj0tGCAKE9Mu0x44be3d+5h3VqbA== X-YMail-OSG: WN7SN1wVM1nzAbeJV7E9LtPCBrHIeQf1a_NwYHycAAr9lT1ZAUR.9E1zO8PmMY3 Jh.hpjMzdiJfWr7bQjkGK.3EC90wTcaknCiARy.3qwdVFW0GywARC9g3R6MjAw.w98evw_lu8aLU Ay9vLk6AdphvGMCx33dMl0c7XSKQ68nqIs3wqczQtLpxWFLSFJpwtM1lPZ_TL3Xn5sqKysdjkTJv rHSjG4rpTqlHjGhW5fnr7QfJN5H5NX_kPK9flWp16vucEHTQ2xEKn9xVdTtIZjzGl37UlzKzlJEF xelCSN.kfcwHUlADEi.e_6WiXZAOFDVi91fZE4vqSTJL1Iw7xVn3ubjGbXMxLRRzRqGlsZxh40Wa 3wudgkttiTF..w0ijj0Ymtx.n7XzfQVHeH2SbcoEvqyW9FkM2wiqiZyTtN_4n7O9EMU7IFBbvBtm ERpayLBrhESKraTf_Ag_5IW46gv6URVB5IKsfwYNxa2swoDsPa2hIcDX9h_Tpea4lhCL_Lae0TER 3kc.OU.bgb1mFmgDyAUc34Dp09P1B1i0ZD0l0fKJEfVZXq5S.PextjLfZowffriQNrW_NGWcE.mS KIFjzU15QbSSqKVL653T.oXidTtbUlnTB37H1w9jqZAz8tnxw7QNgR_NHvgg0JlvaCNAOsATBgjy 2PDQlmyLwU_8PB6EGozmihaHz3udwViNMNv9rXGj7SKyYM9X9OfJw0SM96LsvRpI7Y1hOOozX5UO EXH6A8xA8ip0oTLbetege0YM9e6YqugsniGoOnQz2fr2DUTeboyr3eyCECOyWqXgEQpRzDE18i84 PgmPnAbYSf37ZmpM4UgBfXKa.W8Q02Vh.ZSGYrJgw5TINRbc3QE030M2Od_3K4Of9x2n0X9V6AXc TzzPkmGangw0oKVwh5ghURJLfVkBu20wJ5VwjuxiXuzdceXgAd8_Dn_O1zTHfehe74r5jMch3Avd QY_ZppXU86hAWlQxWrGKAWkH5ynlcgjK2cUmYJH7ACeDQkkaMCxyWH3mJFo.Oe4.bGf2lCpHls0T IJk2ltKJscmfixKryDBsoo3dpucDeauuWKTY9wJ7odIy3i6hLvPw.BKm9Di3BHzO4HX6BVWobsnw tICzEAA0oAJInpLDB_Vz7xoxmKlnqYYXeyk6J51ea5KPNMQnHKmK5IPzdju8a0tfRDbjfGUIaaZn HgEkApx3UDNxEU9jDaA.uj.mrRD7XMc3ECQzXjplW9e6rN2i5H_uGCD4fsOeLJXGWDIS6VDGAwFG rRHtkgO.HVzeoQ_PWJxOXUlIFvUvQKstSUL7LSa8WLWazEnRWIxUeXut_ba1euqnuKpB5gwLpxsj yNQyhh9xvoA6gXbOclTr7gNXOKFSvwFSZNxHmJn7lWdqvQ1G7213sZf3oZwSX_cby45nkTXbbcz8 5FtRZZiQ8gRnQ0.j0.hlAVaKm7b_uA4z9IjXPcqUqlLk7qwn5g71vtjD4Okrpc3Zfl1tFMI7kNHO qGOQSjikZlj6GQ2Pr0MArHF5Ipxc43YOCRw5rmMOHzZYl0AytNlQzaE9vFiMZEUSsdmwYt0ihfN0 XLIsreaUwkHTxr41Fa1Lm1z1_Cjl7LLDJZpCWYRmnz2hycoY6UXOvuqtIeCB1Wyf482x1IewZrtR 4KDMY7kVqcAYouCGKEkYf_XutWCWuh1cgGROEtv6Uq0BrOIj_aA.KqIuhnWu033oPadz8WfgKElU CximrCC5u02A7Y5pIK3ahReDLaHBVQF3Mkkw06gxKdJKcksBtVyK7z1MBvhDkwMiDs8XVOuYSvdm Q4K9TQtAIRQQx.QxWxJQNq71IQkHf_jkK6b74YYoWCXlK8eKKIxbl3A0AKsaUY.t2PIxXvj7nkeH eFYRTyyNPyy3t7i5E6fOjj5qAV7_HJdplmcIPsfdsqTM26KVv8QBpY4M7MKhG.qpLvzk8CxwwnOw 7kkVlauDAU7rLUe7dqjL6K7HI1IWxHVt5sGq0uxDyCESlvOT6j40Jv8YQEPdM2yU0tKUrmz6hvRf gLxQRdV93.8J02IxwCEcy4ng2MjQrXKj.3YuXfi4hwXok3UfMXoL3XqL_d_hZHhcera3_WxMQiTK jUc44tKujJ9o2mMwYbOIPSmM9zKjFu8XCXUf.gvcc_IxVBhqgXk._Lu7k0MGJxTDLlqaqdL1TCR2 ZlgXrimw2hmTZ_FwC36E2mRdb3JW5si41_kdK5rSGH1NesMej3_toCETCSKkjEeD8LhSwUIVPaDQ EQXzPUzDmL6GrAmkBrCn4EBq60u4m3omlQ3DCVzRdlFJ4xZ1oHpSBuR8fK8znZwSTB_HU5Acsrzx JPH0oLQEb.t4XYi04wVsXBY_IMg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Mon, 28 Jun 2021 22:11:19 +0000 Received: by kubenode503.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e2ff5b4c72c268af2e9aa79d29da4757; Mon, 28 Jun 2021 22:11:17 +0000 (UTC) From: Ergus To: bug-gnu-emacs@gnu.org Subject: 28.0.50; project.el+tramp performance issue Date: Tue, 29 Jun 2021 00:11:00 +0200 Message-ID: <87fsx13aiz.fsf@aol.com> MIME-Version: 1.0 Content-Type: text/plain References: <87fsx13aiz.fsf.ref@aol.com> X-Mailer: WebService/1.1.18469 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Content-Length: 12506 Received-SPF: pass client-ip=74.6.135.42; envelope-from=spacibba@aol.com; helo=sonic302-3.consmr.mail.bf2.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Hi: Using tramp I tried to use project.el with a command like project-switch-to-buffer and it took like 10 minutes to complete. I ran a profiler and I found that most of the time was taken by an external function: global-tags-try-project-root project-current is called in a loop for all the opened buffers it calls project--find-in-directory that calls project-find-functions and there is going all the time. After some optimization in an external package; now the time is half than before but still very slow to use the command (around 3-5 minutes to complete) and running again the profiler I get this: 5637 89% - command-execute 5549 88% - byte-code 5549 88% - project--read-project-buffer 5549 88% - let* 5336 85% - read-buffer 5323 84% - ivy-completing-read 5323 84% - ivy-read 4941 78% - ivy--reset-state 4941 78% - ivy--buffer-list 4941 78% - internal-complete-buffer 4941 78% - # 4941 78% - and 4941 78% - equal 4941 78% - save-current-buffer 4941 78% - project-current 4941 78% - project--find-in-directory 4548 72% - project-try-vc 4537 72% - vc-responsible-backend 4478 71% - # 4478 71% - vc-call-backend 4478 71% - apply 1470 23% + vc-svn-responsible-p 1142 18% + vc-bzr-responsible-p 970 15% + vc-hg-responsible-p 390 6% + vc-git-responsible-p 156 2% + vc-cvs-responsible-p 126 2% + vc-rcs-responsible-p 108 1% + vc-sccs-responsible-p 98 1% + vc-src-responsible-p 57 0% + tramp-file-name-handler 11 0% + vc-file-getprop 393 6% + global-tags-try-project-root 375 5% + read-from-minibuffer 13 0% + if 213 3% + project-current 88 1% + funcall-interactively 572 9% + ... 51 0% + timer-event-handler 8 0% + redisplay_internal (C function) As you can see most of the time is still taken by project-current and I can't really understand why: 1) Are so many samples 4548 seems a very high number for only 25 opened buffers. 2) why project-try-vc still takes so much...? Specially for unfrequent vc systems in our days like svn or bzr that I am not using. 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. 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. Related with https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42966 VCS changing is not something that happens very often to require a check of all the backends everytime, several times for every buffer in many project.el functions right? Specially when using tramp. vc has vc-file-prop-obarray; maybe vc-responsible-backend should cache it's result there to avoid repeating time consuming computations? Either in the local system the performance penalty seems to be significant to me. Best, Ergus In GNU Emacs 28.0.50 (build 50, x86_64-pc-linux-gnu, GTK+ Version 3.24.29, cairo version 1.17.4) of 2021-06-26 built on Ergus Repository revision: b8f9e58ef72402e69a1f0960816184d52e5d2d29 Repository branch: master System Description: Arch Linux Configured using: 'configure --prefix=/home/ergo/.local/ --with-mailutils --with-json --with-x-toolkit=gtk3 --with-xft --with-wide-int --with-modules --with-cairo --with-harfbuzz --with-native-compilation' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON LCMS2 LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: C++//law Minor modes in effect: global-git-commit-mode: t magit-auto-revert-mode: t diff-hl-margin-mode: t windmove-mode: t subword-mode: t hide-ifdef-mode: t preproc-font-lock-mode: t shell-dirtrack-mode: t show-paren-mode: t global-auto-revert-mode: t xclip-mode: t yas-global-mode: t yas-minor-mode: t electric-pair-mode: t flyspell-mode: t company-mode: t flycheck-mode: t counsel-mode: t ivy-mode: t composable-mark-mode: t composable-mode: t repeat-mode: t xterm-mouse-mode: t winner-mode: t save-place-mode: t which-key-mode: t override-global-mode: t delete-selection-mode: t savehist-mode: t global-display-fill-column-indicator-mode: t display-fill-column-indicator-mode: t global-display-line-numbers-mode: t display-line-numbers-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t size-indication-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t abbrev-mode: t Load-path shadows: /usr/share/emacs/site-lisp/cmake-mode hides /home/ergo/.emacs.d/elpa/cmake-mode-20210104.1831/cmake-mode /usr/share/emacs/site-lisp/notmuch-crypto hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-crypto /usr/share/emacs/site-lisp/notmuch-compat hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-compat /usr/share/emacs/site-lisp/notmuch-hello hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-hello /usr/share/emacs/site-lisp/notmuch hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch /usr/share/emacs/site-lisp/notmuch-show hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-show /usr/share/emacs/site-lisp/notmuch-maildir-fcc hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-maildir-fcc /usr/share/emacs/site-lisp/coolj hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/coolj /usr/share/emacs/site-lisp/notmuch-draft hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-draft /usr/share/emacs/site-lisp/notmuch-tree hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-tree /usr/share/emacs/site-lisp/notmuch-parser hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-parser /usr/share/emacs/site-lisp/notmuch-lib hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-lib /usr/share/emacs/site-lisp/notmuch-mua hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-mua /usr/share/emacs/site-lisp/notmuch-message hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-message /usr/share/emacs/site-lisp/notmuch-address hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-address /usr/share/emacs/site-lisp/notmuch-wash hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-wash /usr/share/emacs/site-lisp/notmuch-tag hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-tag /usr/share/emacs/site-lisp/notmuch-print hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-print /usr/share/emacs/site-lisp/notmuch-query hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-query /usr/share/emacs/site-lisp/notmuch-jump hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-jump /usr/share/emacs/site-lisp/notmuch-company hides /home/ergo/.emacs.d/elpa/notmuch-20210627.1741/notmuch-company /home/ergo/.emacs.d/elpa/transient-20210619.1100/transient hides /home/ergo/.local/share/emacs/28.0.50/lisp/transient Features: (shadow sort notmuch-company notmuch-lib notmuch-version notmuch-compat mm-view mml-smime smime dig mail-extr emacsbug sendmail magit-extras hi-lock magit-bookmark magit-submodule magit-obsolete magit-blame magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit magit-sequence magit-notes magit-worktree magit-tag magit-merge magit-branch magit-reset magit-files magit-refs magit-status magit package browse-url url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util mailcap url-handlers magit-repos magit-apply magit-wip magit-log which-func imenu magit-diff smerge-mode diff git-commit log-edit message rmc puny rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader add-log magit-core magit-autorevert magit-margin magit-transient magit-process with-editor server magit-mode transient magit-git magit-section magit-utils crm tramp-cmds global-tags ht generator async counsel-gtags pulse mc-separate-operations mc-edit-lines mc-hide-unmatched-lines-mode mc-mark-more mc-cycle-cursors multiple-cursors-core rect move-dup diff-hl-margin eieio-opt speedbar ezimage dframe shortdoc help-fns radix-tree vc-annotate amx s windmove misearch multi-isearch ffap url-parse url-vars face-remap vc-hg macrostep-c cmacexp macrostep cap-words superword subword hideif preproc-font-lock cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs dired-aux diff-hl-dired diff-hl log-view pcvs-util vc-dir ewoc vc tramp-cache tramp-sh tramp tramp-loaddefs trampver tramp-integration files-x tramp-compat shell pcomplete parse-time iso8601 time-date ls-lisp format-spec auth-source password-cache thingatpt vc-git diff-mode vc-dispatcher bookmark pp paren autorevert filenotify xclip yasnippet-snippets yasnippet elec-pair flyspell-correct-ivy flyspell-correct flyspell ispell company-keywords company-gtags company-dabbrev-code company-dabbrev company-files company-semantic company-template company-capf company flycheck json map find-func dash counsel xdg xref project dired-x dired dired-loaddefs compile text-property-search comint ansi-color swiper ivy-avy avy ivy flx ivy-faces ivy-overlay colir pcase term/tmux term/xterm xterm jka-compr init composable composable-mark powerline comp comp-cstr warnings subr-x powerline-separators color powerline-themes repeat xt-mouse simple-16-theme winner ring saveplace diminish edmacro kmacro which-key advice configmail cl-extra help-mode use-package use-package-ensure use-package-delight use-package-diminish use-package-bind-key bind-key use-package-core disp-table delsel savehist easy-mmode display-fill-column-indicator display-line-numbers info ede/auto eieio-base cl-seq seq eieio byte-opt bytecomp byte-compile cconv eieio-core cl-macs gv eieio-loaddefs cl-loaddefs cl-lib tex-site rx slime-autoloads early-init iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit x multi-tty make-network-process native-compile emacs) Memory information: ((conses 16 811583 75249) (symbols 48 30651 0) (strings 32 107218 13868) (string-bytes 1 4408538) (vectors 16 57480) (vector-slots 8 1324399 45245) (floats 8 342 1198) (intervals 56 53473 1428) (buffers 992 37)) ------------=_1629543602-15317-1--