* Re: emacs-27 e1e0a7a 2/2: xref--collect-matches: Speed up on remote
[not found] ` <20191227141919.03F1321537@vcs0.savannah.gnu.org>
@ 2019-12-27 15:58 ` Stefan Monnier
2019-12-27 16:18 ` Dmitry Gutov
0 siblings, 1 reply; 11+ messages in thread
From: Stefan Monnier @ 2019-12-27 15:58 UTC (permalink / raw)
To: emacs-devel; +Cc: Dmitry Gutov
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: emacs-27 e1e0a7a 2/2: xref--collect-matches: Speed up on remote
2019-12-27 15:58 ` emacs-27 e1e0a7a 2/2: xref--collect-matches: Speed up on remote Stefan Monnier
@ 2019-12-27 16:18 ` Dmitry Gutov
2019-12-27 19:30 ` Stefan Monnier
0 siblings, 1 reply; 11+ messages in thread
From: Dmitry Gutov @ 2019-12-27 16:18 UTC (permalink / raw)
To: Stefan Monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: emacs-27 e1e0a7a 2/2: xref--collect-matches: Speed up on remote
2019-12-27 16:18 ` Dmitry Gutov
@ 2019-12-27 19:30 ` Stefan Monnier
2019-12-27 20:19 ` Michael Albinus
0 siblings, 1 reply; 11+ messages in thread
From: Stefan Monnier @ 2019-12-27 19:30 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: emacs-devel
>>> + (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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: emacs-27 e1e0a7a 2/2: xref--collect-matches: Speed up on remote
2019-12-27 19:30 ` Stefan Monnier
@ 2019-12-27 20:19 ` Michael Albinus
2019-12-27 22:06 ` Stefan Monnier
0 siblings, 1 reply; 11+ messages in thread
From: Michael Albinus @ 2019-12-27 20:19 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel, Dmitry Gutov
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: emacs-27 e1e0a7a 2/2: xref--collect-matches: Speed up on remote
2019-12-27 20:19 ` Michael Albinus
@ 2019-12-27 22:06 ` Stefan Monnier
2019-12-28 10:09 ` Michael Albinus
2019-12-28 15:22 ` Dmitry Gutov
0 siblings, 2 replies; 11+ messages in thread
From: Stefan Monnier @ 2019-12-27 22:06 UTC (permalink / raw)
To: Michael Albinus; +Cc: emacs-devel, Dmitry Gutov
>> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: emacs-27 e1e0a7a 2/2: xref--collect-matches: Speed up on remote
2019-12-27 22:06 ` Stefan Monnier
@ 2019-12-28 10:09 ` Michael Albinus
2019-12-28 16:53 ` Stefan Monnier
2019-12-28 15:22 ` Dmitry Gutov
1 sibling, 1 reply; 11+ messages in thread
From: Michael Albinus @ 2019-12-28 10:09 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel, Dmitry Gutov
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: emacs-27 e1e0a7a 2/2: xref--collect-matches: Speed up on remote
2019-12-27 22:06 ` Stefan Monnier
2019-12-28 10:09 ` Michael Albinus
@ 2019-12-28 15:22 ` Dmitry Gutov
2019-12-28 16:54 ` Stefan Monnier
2019-12-28 18:58 ` Michael Albinus
1 sibling, 2 replies; 11+ messages in thread
From: Dmitry Gutov @ 2019-12-28 15:22 UTC (permalink / raw)
To: Stefan Monnier, Michael Albinus; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: emacs-27 e1e0a7a 2/2: xref--collect-matches: Speed up on remote
2019-12-28 10:09 ` Michael Albinus
@ 2019-12-28 16:53 ` Stefan Monnier
0 siblings, 0 replies; 11+ messages in thread
From: Stefan Monnier @ 2019-12-28 16:53 UTC (permalink / raw)
To: Michael Albinus; +Cc: emacs-devel, Dmitry Gutov
> Should be, yes. And according to some short tests, Tramp behaves like this.
Thanks for confirming,
Stefan
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: emacs-27 e1e0a7a 2/2: xref--collect-matches: Speed up on remote
2019-12-28 15:22 ` Dmitry Gutov
@ 2019-12-28 16:54 ` Stefan Monnier
2019-12-28 16:58 ` Dmitry Gutov
2019-12-28 18:58 ` Michael Albinus
1 sibling, 1 reply; 11+ messages in thread
From: Stefan Monnier @ 2019-12-28 16:54 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: Michael Albinus, emacs-devel
>> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: emacs-27 e1e0a7a 2/2: xref--collect-matches: Speed up on remote
2019-12-28 16:54 ` Stefan Monnier
@ 2019-12-28 16:58 ` Dmitry Gutov
0 siblings, 0 replies; 11+ messages in thread
From: Dmitry Gutov @ 2019-12-28 16:58 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Michael Albinus, emacs-devel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: emacs-27 e1e0a7a 2/2: xref--collect-matches: Speed up on remote
2019-12-28 15:22 ` Dmitry Gutov
2019-12-28 16:54 ` Stefan Monnier
@ 2019-12-28 18:58 ` Michael Albinus
1 sibling, 0 replies; 11+ messages in thread
From: Michael Albinus @ 2019-12-28 18:58 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: Stefan Monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2019-12-28 18:58 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20191227141917.13328.16721@vcs0.savannah.gnu.org>
[not found] ` <20191227141919.03F1321537@vcs0.savannah.gnu.org>
2019-12-27 15:58 ` emacs-27 e1e0a7a 2/2: xref--collect-matches: Speed up on remote Stefan Monnier
2019-12-27 16:18 ` Dmitry Gutov
2019-12-27 19:30 ` Stefan Monnier
2019-12-27 20:19 ` Michael Albinus
2019-12-27 22:06 ` Stefan Monnier
2019-12-28 10:09 ` Michael Albinus
2019-12-28 16:53 ` Stefan Monnier
2019-12-28 15:22 ` Dmitry Gutov
2019-12-28 16:54 ` Stefan Monnier
2019-12-28 16:58 ` Dmitry Gutov
2019-12-28 18:58 ` Michael Albinus
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).