GNU bug report logs - #63651
possible eglot xref-find-references optimization

Previous Next

Full log

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

From: Alan Donovan <adonovan <at> google.com>
To: bug-gnu-emacs <at> gnu.org
Subject: possible eglot xref-find-references optimization
Date: Mon, 22 May 2023 13:45:57 -0400

Hi João & other eglot folks,

I've been doing a small amount of digging into what makes VSCode so
relatively fast. One item that I noticed is that eglot, in the loop
that it does over the references obtained from the LSP server, calls
find-buffer-visiting to avoid re-reading files that are already open
in buffers. I'm not sure whether this is just an optimization, or
whether it is necessary to ensure that modified buffer contents are
rendered correctly, but it's noticeably slow: for one large query that
results in an xref buffer of 1300 lines, the operation takes about 2s
normally, but only about 0.8s when I replace the find-buffer-visiting
call with false. (According to the elisp CPU profiler,
find-buffer-visiting calls file-truename, recursively, a lot.)

(defun eglot--xref-make-match (name uri range)
  "Like `xref-make-match' but with LSP's NAME, URI and RANGE.
Try to visit the target file for a richer summary line."
  (pcase-let*
      ((file (eglot--uri-to-path uri))
       (visiting (or (find-buffer-visiting file) ;; <--- replace this with false
                     (gethash uri eglot--temp-location-buffers)))
       (collect (lambda ()
...

Would that change be sound? Or is it necessary for the reason I
guessed at (or some other reason)?

cheers
alan

Previous Next

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