tramp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: File path completions: strange speed discrepancy


From: JD Smith
Subject: Re: File path completions: strange speed discrepancy
Date: Tue, 21 Sep 2021 09:42:55 -0400



On Sep 21, 2021, at 9:15 AM, Michael Albinus <michael.albinus@gmx.de> wrote:

JD Smith <jdtsmith@gmail.com> writes:

One thing I don’t understand is why tramp needs to re-evaluate the
standard value of the variable `temporary-file-directory’ at all.
That variable doesn’t appear to change on remote hosts, or ever
really.  What does change is the returned result of the
identically-name function `temporary-file-directory’.  

Tramp needs a trustworthy value on the local host. There were bug
reports, that this variable got another value, somewhere else (even
remote!), which has broken Tramp. That's why I have introduced this
defsubst.

OK great.  In the meantime people can also:

 ;; Workaround a tramp-MacOS bug that dramatically slows completion
  (put 'temporary-file-directory 'standard-value
       (list temporary-file-directory))


A quick fix for me was simply to (see FIXED timing, below):

   (defsubst tramp-compat-temporary-file-directory ()
     "Return name of directory for temporary files.
   It is the default value of `temporary-file-directory'."
     temporary-file-directory)

I have fixed this slightly different: I've changed the defsubst to a
defconst. All callees need to be changed, but that's simple.

Will be available with next Tramp 2.5.1.3, roughly in a week.

Excellent, thank you!

I note that this remains an issue in Emacs 28.1 and Tramp v2.5.1.2.

Yes, there are still discrepancies in my tests (I'm running GNU/Linux),
mainly in tramp-sh-handle-expand-file-name:

I meant only that this darwin-shell-calling behavior hadn’t yet been fixed on those newer versions, but I anticipate 2.5.1.3 will fix it for v28.1 as well (for darwin users).  People with fast-starting shells (or users of sshx, which spawns its own /bin/sh) won’t likely notice any real difference (1.5-2x slowdown is harder to notice than 10-20x slowdown!).  

Running on "/"

read-file-name-default                          1           0.866070978   0.866070978
completing-read                                 1           0.864735142   0.864735142
completion-file-name-table                      21          0.7882453620  0.0375354934
...

Running on "/ssh::"

read-file-name-default                          1           6.540671391   6.540671391
tramp-sh-handle-expand-file-name                408         4.9722099110  0.0121867889
completing-read                                 1           1.586810819   1.586810819
completion-file-name-table                      21          1.3919740299  0.0662844776
...

So there is still something to be investigated in
tramp-sh-handle-expand-file-name. But since this is the test case we have
started on a remote default-directory, it might be OK. At least the time
for tramp-sh-handle-expand-file-name is not cumulated in
completing-read. Will see.

This is indeed strange, and oddly the reverse discrepancy of what I found (for me: remote was fast, local was slow). 

I’m not sure if it’s related, but I did discover one additional curiosity: (getenv “TMPDIR”) returns the same value as getconf DARWIN_USER_TEMP_DIR, so on Mac the defsubst shouldn’t ever call out to a shell.  Debugging this somewhat, I see that some of the time during tramp-sh-handle-expand-file-name, (getenv “TMPDIR”) returns nil.  Is this expected?  I.e. does tramp alter or clear the environment during some of its call paths?  I still think the defconst is a good fix, since there’s no need even to “getenv” something that is constant.  But the "disappearing environment” may represent a deeper bug, perhaps related to your remaining issue.  

I’ll give 2.5.1.3 a test; let me know if you have a release candidate I can try. 

Best,
JDS


reply via email to

[Prev in Thread] Current Thread [Next in Thread]