Re: emacs-27 e1e0a7a 2/2: xref--collect-matches: Speed up on remote

Re: emacs-27 e1e0a7a 2/2: xref--collect-matches: Speed up on remote

[Stefan Monnier]

Dmitry Gutov [2019-12-27 09:19:18] wrote:

> +               (buf (unless remote-id
> +                      ;; find-buffer-visiting is slow on remote.
> +                      (xref--find-buffer-visiting file)))

How 'bout using `get-file-buffer` instead, then?


        Stefan

Re: emacs-27 e1e0a7a 2/2: xref--collect-matches: Speed up on remote

[Dmitry Gutov]

On 27.12.2019 17:58, Stefan Monnier wrote:
> Dmitry Gutov [2019-12-27 09:19:18] wrote:
> 
>> +               (buf (unless remote-id
>> +                      ;; find-buffer-visiting is slow on remote.
>> +                      (xref--find-buffer-visiting file)))
> 
> How 'bout using `get-file-buffer` instead, then?

Good idea. Still slower on remote files, but much faster overall.

Thanks, pushed.

Re: emacs-27 e1e0a7a 2/2: xref--collect-matches: Speed up on remote

[Stefan Monnier]

>>> +               (buf (unless remote-id
>>> +                      ;; find-buffer-visiting is slow on remote.
>>> +                      (xref--find-buffer-visiting file)))
>> How 'bout using `get-file-buffer` instead, then?
> Good idea. Still slower on remote files, but much faster overall.

Hmm... why is it slower on remote files?  AFAIK it all works locally.
It does go through Tramp for the initial `expand-file-name`, but AFAIK
this shouldn't need to talk to the remote host (unless it has a ~/ or
~<user>/ in the remote part of the name, I guess?).


        Stefan

Re: emacs-27 e1e0a7a 2/2: xref--collect-matches: Speed up on remote

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> It does go through Tramp for the initial `expand-file-name`, but AFAIK
> this shouldn't need to talk to the remote host (unless it has a ~/ or
> ~<user>/ in the remote part of the name, I guess?).

That's how it is implemented, yes. However, remote file names with a
relative localname part, are also expanded via prepending "~/" to the
localname. For performance reasons it is better to avoid such file names.

>         Stefan

Best regards, Michael.

Re: emacs-27 e1e0a7a 2/2: xref--collect-matches: Speed up on remote

[Stefan Monnier]

>> It does go through Tramp for the initial `expand-file-name`, but AFAIK
>> this shouldn't need to talk to the remote host (unless it has a ~/ or
>> ~<user>/ in the remote part of the name, I guess?).
> That's how it is implemented, yes. However, remote file names with a
> relative localname part, are also expanded via prepending "~/" to the
> localname. For performance reasons it is better to avoid such file names.

In the context of `xref--collect-matches`, I'd expect the file name passed
to `get-file-buffer` to be either fully expanded file names or relative
file names (with a fully expanded `default-directory`), so in that case
`expand-file-name` should presumably "always" return without contacting
the remote host, right?


        Stefan

Re: emacs-27 e1e0a7a 2/2: xref--collect-matches: Speed up on remote

[Michael Albinus]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> It does go through Tramp for the initial `expand-file-name`, but AFAIK
>>> this shouldn't need to talk to the remote host (unless it has a ~/ or
>>> ~<user>/ in the remote part of the name, I guess?).
>> That's how it is implemented, yes. However, remote file names with a
>> relative localname part, are also expanded via prepending "~/" to the
>> localname. For performance reasons it is better to avoid such file names.
>
> In the context of `xref--collect-matches`, I'd expect the file name passed
> to `get-file-buffer` to be either fully expanded file names or relative
> file names (with a fully expanded `default-directory`), so in that case
> `expand-file-name` should presumably "always" return without contacting
> the remote host, right?

Should be, yes. And according to some short tests, Tramp behaves like this.

>         Stefan

Best regards, Michael.

Re: emacs-27 e1e0a7a 2/2: xref--collect-matches: Speed up on remote

[Dmitry Gutov]

On 28.12.2019 0:06, Stefan Monnier wrote:
> so in that case
> `expand-file-name` should presumably "always" return without contacting
> the remote host, right?

Personally, I don't see why file-local-name should ever call 
expand-file-name. The caller can do that itself, when necessary.

Re: emacs-27 e1e0a7a 2/2: xref--collect-matches: Speed up on remote

[Stefan Monnier]

> Should be, yes. And according to some short tests, Tramp behaves like this.

Thanks for confirming,


        Stefan

Re: emacs-27 e1e0a7a 2/2: xref--collect-matches: Speed up on remote

[Stefan Monnier]

>> so in that case `expand-file-name` should presumably "always" return
>> without contacting the remote host, right?
> Personally, I don't see why file-local-name should ever call
> expand-file-name.  The caller can do that itself, when necessary.

I think I agree, but I don't see how that relates to the discussion, so
maybe I'm missing something (I can't remember any reference to `file-local-name`).


        Stefan

Re: emacs-27 e1e0a7a 2/2: xref--collect-matches: Speed up on remote

[Dmitry Gutov]

On 28.12.2019 18:54, Stefan Monnier wrote:
>>> so in that case `expand-file-name` should presumably "always" return
>>> without contacting the remote host, right?
>> Personally, I don't see why file-local-name should ever call
>> expand-file-name.  The caller can do that itself, when necessary.
> 
> I think I agree, but I don't see how that relates to the discussion, so
> maybe I'm missing something (I can't remember any reference to `file-local-name`).

Oh, right, sorry.

See the discussion here: 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34343#38

Re: emacs-27 e1e0a7a 2/2: xref--collect-matches: Speed up on remote

[Michael Albinus]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 28.12.2019 0:06, Stefan Monnier wrote:
>> so in that case
>> `expand-file-name` should presumably "always" return without contacting
>> the remote host, right?
>
> Personally, I don't see why file-local-name should ever call
> expand-file-name. The caller can do that itself, when necessary.

In the current implementation, file-local-name calls file-remote-p,
which sometimes calls expand-file-name. There are reasons for this, but
for the file-local-name business this is unfortune.

Best regards, Michael.