* 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-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-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 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).