GNU bug report logs - #73718
31.0.50; Severe performance issue with Tramp and project-mode-line-format

Previous Next

Full log

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

From: Ship Mints <shipmints <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Ergus <spacibba <at> aol.com>, Michael Albinus <michael.albinus <at> gmx.de>,
 73718 <at> debbugs.gnu.org, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#73718: 31.0.50;
 Severe performance issue with Tramp and project-mode-line-format
Date: Fri, 11 Oct 2024 10:35:06 -0400

[Message part 1 (text/plain, inline)]

In addition to guarding project-try-vc, I also have a customized cache for
non-projects specifically to get around the incessant retesting for what
are effectively invariant conditions.

If of any utility to others:

(use-package project
...
  (defconst my:project--non-project-dir ".") ; nil disables the cache;
NOTE: eglot relies on project-root so this has to be a real path
  (defun my/project-try-non-project-cache (dir)
    (unless (and my:project-vc-inhibit-remote (file-remote-p dir)) ; yet
another optional remote guard
      (let ((proj (cons 'transient (or my:project--non-project-dir
(expand-file-name dir)))))
        (vc-file-setprop dir 'project-vc proj) ; project caches via vc
internal properties
        proj)))
  (add-to-list 'project-find-functions #'my/project-try-non-project-cache
'append))

  ;; customized project current name function that respects
  ;; non-project marker and returns nil if a non-project
  (defun my/project-current-name (&optional buf)
    "Return the current project name for BUF, or nil if a non-project.
If BUF is nil, the current buffer is used."
    (with-current-buffer (or buf (current-buffer))
      (when-let* ((p (project-current))
                  (pn (project-name p)))
        (unless (string= pn my:project--non-project-dir)
          pn))))
...
)

On Thu, Oct 10, 2024 at 8:38 PM Dmitry Gutov <dgutov <at> yandex.ru> wrote:

> On 09/10/2024 19:10, Juri Linkov wrote:
> > Or maybe better to cache the value of project-name on remove projects.
>
> Just the project->project-name mapping? Why not. I suppose there'd still
> be a pause when switching projects, but it's not as bad.
>
> For general caching, from past threads it seems the most problematic
> case is "no project". Because OT1H it's still costly it terms of remote
> I/O. But on the other, this is exactly when the cache might get invalid
> soon (because the user will initialize a Git repo, or create another
> root marker, etc).
>
> I guess we should come back to this after bug#72300.
>
>
>
>

[Message part 2 (text/html, inline)]

Previous Next

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