global-tags performance issue and proposed fix about emacs-counsel-gtags

[Ergus]

(cl-defun global-tags--get-dbpath (&optional (dir default-directory))
  "Filepath for database from DIR."
  (pcase (gethash dir global-tags--dbpath-cache)
    ('empty nil)
    ('nil
     (puthash dir 'empty global-tags--dbpath-cache)
     (when-let* 
       === BLA ===
       (when (file-exists-p dbpath)
	 (puthash dir dbpath global-tags--dbpath-cache))))
    (code code)))

[FelipeLema]

I'm actually using somewhat the first solution you propose, using cache, at work. I hadn't updated that code, although it's stable now. I'm actually inheriting wrapping global-tags-try-project-root with a function that first checks cached roots before calling any global-tags function. This is a great feature of the extensible design of project.el and xref.el

what I'm doing is using a persist-defvar with a list of already-used "project roots per gtags". Since I don't tend to delete source code at work, I've never had to worry about that list including deleted code. I don't know if it's the same for anyone else, but I guess that a Emacs-session-local var should be enough for everyone.

Should we have a timeout for cached project roots? How much? 24h? Refreshing the cache list can be done in the background using async, so that's not a problem.

[Ergus]

I'm actually using somewhat the first solution you propose, using cache, at work. I hadn't updated that code, although it's stable now. I'm actually inheriting wrapping global-tags-try-project-root with a function that first checks cached roots before calling any global-tags function. This is a great feature of the extensible design of project.el and xref.el

The second solution is actually better because project-find-functions may have more than one function to try, and it is useful to avoid repeating the search with global-tags--get-dbpath when it failed in this session once.

I actually reported an emacs bug bug#49264 to see if they add some caching features to project.el because the vc backend is also very slow.

what I'm doing is using a persist-defvar with a list of already-used "project roots per gtags". Since I don't tend to delete source code at work, I've never had to worry about that list including deleted code. I don't know if it's the same for anyone else, but I guess that a Emacs-session-local var should be enough for everyone.

Should we have a timeout for cached project roots? How much? 24h? Refreshing the cache list can be done in the background using async, so that's not a problem.

That may be a custom... so 0 means disable cache, a number the time in whatever unit you want and nil disable auto erasing.