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@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.
>
>
>
>