JD Smith <email@example.com
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
OK great. In the meantime people can also:
;; Workaround a tramp-MacOS bug that dramatically slows completion
(put 'temporary-file-directory 'standard-value
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'."
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 184.108.40.206, roughly in a week.
Excellent, thank you!
I note that this remains an issue in Emacs 28.1 and Tramp v220.127.116.11.
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 18.104.22.168 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 22.214.171.124 a test; let me know if you have a release candidate I can try.