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

Previous Next

To reply to this bug, email your comments to 63651 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

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

From: João Távora <joaotavora <at> gmail.com>
To: Alan Donovan <adonovan <at> google.com>
Cc: 63651 <at> debbugs.gnu.org
Subject: Re: bug#63651: possible eglot xref-find-references optimization
Date: Wed, 24 May 2023 17:28:58 +0100

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

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

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

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

From: Alan Donovan <adonovan <at> google.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: 63651 <at> debbugs.gnu.org
Subject: Re: bug#63651: possible eglot xref-find-references optimization
Date: Wed, 24 May 2023 17:22:48 -0400

On Wed, 24 May 2023 at 12:29, João Távora <joaotavora <at> 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

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

From: Alan Donovan <adonovan <at> google.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: 63651 <at> debbugs.gnu.org
Subject: Re: bug#63651: possible eglot xref-find-references optimization
Date: Tue, 4 Jul 2023 09:55:57 -0400

Any progress? Were you able to observe the problem?

cheers
alan

On Wed, 24 May 2023 at 17:22, Alan Donovan <adonovan <at> google.com> wrote:
>
> On Wed, 24 May 2023 at 12:29, João Távora <joaotavora <at> 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

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Alan Donovan <adonovan <at> google.com>, João Távora
 <joaotavora <at> gmail.com>
Cc: 63651 <at> debbugs.gnu.org
Subject: Re: bug#63651: possible eglot xref-find-references optimization
Date: Sat, 5 Oct 2024 02:36:30 +0300

Hi!

On 04/07/2023 16:55, Alan Donovan via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> Any progress? Were you able to observe the problem?

Sorry this report got dropped.

I've tried reproducing and see some difference when using Emacs 29. 
Since as you mention it's due to find-buffer-visiting call, this likely 
only manifests with a significant number of buffers open.

'git blame' on the call in question leads to 
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=306feb7d967e - I 
haven't dug in too much further to say more.

But I suggest you retry your scenario using Emacs 30 (currently in 
pretest) - performance of find-buffer-visiting is improve in it. Seems 
to make a difference here.

> cheers
> alan
> 
> On Wed, 24 May 2023 at 17:22, Alan Donovan <adonovan <at> google.com> wrote:
>>
>> On Wed, 24 May 2023 at 12:29, João Távora <joaotavora <at> 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
> 
> 
> 

Previous Next

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