bug#63651: possible eglot xref-find-references optimization

bug#63651: possible eglot xref-find-references optimization

[Alan Donovan via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

bug#63651: possible eglot xref-find-references optimization

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 404 bytes --]

Thanks for reporting this Alan, it is an interesting point. (Next time you
can add me on CC directly so that i don't miss the message in this list,
which i don't always track closely)

Could you provide a test case where these ~= 1300 xref matches are
produced? I suppose it is some Go repository? With a standard gopls? But
which file/position and which command should one use?

Thanks,
João

[-- Attachment #2: Type: text/html, Size: 549 bytes --]

bug#63651: possible eglot xref-find-references optimization

[Alan Donovan via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Wed, 24 May 2023 at 12:29, João Távora <joaotavora@gmail.com> wrote:
> Thanks for reporting this Alan, it is an interesting point. (Next time you can add me on CC directly so that i don't miss the message in this list, which i don't always track closely)

Will do.

> Could you provide a test case where these ~= 1300 xref matches are produced? I suppose it is some Go repository? With a standard gopls? But which file/position and which command should one use?

$ git clone https://github.com/golang/tools
$ cd tools
$ (cd gopls && go install)   # if you don't have it already
$ emacs gopls/internal/lsp/cache/analysis.go
Then search for fmt.Sprintf (e.g. on L246) and do xref-find-references
on it. I get about 1300 matches.

cheers
alan

bug#63651: possible eglot xref-find-references optimization

[Alan Donovan via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Any progress? Were you able to observe the problem?

cheers
alan

On Wed, 24 May 2023 at 17:22, Alan Donovan <adonovan@google.com> wrote:
>
> On Wed, 24 May 2023 at 12:29, João Távora <joaotavora@gmail.com> wrote:
> > Thanks for reporting this Alan, it is an interesting point. (Next time you can add me on CC directly so that i don't miss the message in this list, which i don't always track closely)
>
> Will do.
>
> > Could you provide a test case where these ~= 1300 xref matches are produced? I suppose it is some Go repository? With a standard gopls? But which file/position and which command should one use?
>
> $ git clone https://github.com/golang/tools
> $ cd tools
> $ (cd gopls && go install)   # if you don't have it already
> $ emacs gopls/internal/lsp/cache/analysis.go
> Then search for fmt.Sprintf (e.g. on L246) and do xref-find-references
> on it. I get about 1300 matches.
>
> cheers
> alan