11

I have always found TRAMP to be crazy slow (5+ secs to fetch a directory listing) so I've avoided it for years. Time to figure out what is going on. I'm always connecting via ssh, using declarations in ~/.ssh/config. The connections are fine, I've survived buy running remote emacs sessions in a terminal.

I figured out how to turn on tramp debugging but not sure how to read the output. It appears that there might be a delay before tramp starts doing anything? Perhaps tramp is conflicting with some other mode?

jmay
  • 363
  • 2
  • 9
  • I don't see this. Does it happen in `emacs -Q`? Does it happen when you try to connect with `ssh` manually? – PythonNut Sep 10 '15 at 02:04
  • I use Emacs built for OSX in GUI mode, and I don't see any unreasonably long wait when connecting to my remote server on a shared box in cyberspace -- liquidweb. I use `dired-mode` when navigating the shared server. However, I don't use a ~/.ssh/config. I just have the `known_hosts` file that gets set up the first time I connected via ssh. Do you have the most recent stable public release of Emacs built for OSX? – lawlist Sep 10 '15 at 03:32
  • 1
    Use `(setq tramp-verbose 6)`. The debug output includes timestamps, this might tell us what happens. Since sx might not be the best medium for discussing traces, you might send them to the Tramp mailing list, or directly to me. – Michael Albinus Sep 10 '15 at 07:27
  • The first thing I do is set `process-connection-type` to `nil` and watch for any relevant bugs [here](http://debbugs.gnu.org/cgi/pkgreport.cgi?include=subject%3Aprocess;package=emacs). – Emacs User Sep 11 '15 at 01:16
  • For me, `tramp-cleanup-all-connections` and `tramp-cleanup-all-buffers` made a difference. – Peter Becich Apr 06 '23 at 03:18

3 Answers3

7

I know it's an old question and that you maybe don't care about the answer now but I do faced the same issue.

I was pretty sure it was OS X related but in fact lags and timeouts were caused by my remote prompt!

Tramp is limited in its remote prompt parsing and relies on it to know if a command has finished or not.

I googled for days always including "os x" in my searches but in fact it's not related at all. As you can see in the official FAQ the remote prompt has to be very simple for Tramp to work. You can tweak the regexp in your Emacs config to avoid changing the prompt on the remote but honestly if you can do it on the remote it's easier.

Just add [ $TERM = "dumb" ] && unsetopt zle && PS1='$ ' to your remote .zshrc or something similar if you use another shell. The point is the prompt as to be $.

Hope it'll help someone.

Bounga
  • 81
  • 1
  • 6
  • Any advice, for the case in which one cannot or prefers not to change the remote prompt, on how to specify the prompt, e.g. for prompts with coloring, which apparently causes parsing problem? – Jesse W. Collins Nov 25 '19 at 20:40
  • 1
    Hi Jess. As I said in my answer, the other solution is to tweak the regexp in your Emacs config to avoid changing the prompt on the remote. This regex is stored in `tramp-shell-prompt-pattern` variable. Tramps relies on this one to parse the remote prompt. Shell prompts that contain escape sequences for coloring are known to cause parsing problems. – Bounga Nov 29 '19 at 14:51
2

My conclusion, after I looked at my traces, was that a major source of delays was checking for all possible VC backends for every file opened. For most backends, that involves directory traversal toward the root to find any containing repository. Since I only ever use git as VC my solution was to set vc-handled-backends to '(git). That didn't make Tramp suddenly rocket fast, but it helped.

q.undertow
  • 314
  • 1
  • 9
1

Unsure if this was the problem here, but there was a long-standing bug on 'darwin (OSX/MacOS) systems in tramp, which caused it to spawn a shell command for remote directories hundreds of times per remote file-path completion. Especially if you have a slow to start shell, this added huge overheads and led to several second apparent file/directory listings lags. This has been fixed in Tramp v2.5.1.3 and later.

JDS
  • 21
  • 3
  • I have magit 3.3.0 on Mac and this particular problem is still there. The workaround I use (found somewhere on bugs.gnu.org) is to force the `predicate` argument to `read-file-name` to be always set, in my rendering to `#'identity`. – q.undertow Aug 26 '22 at 19:48
  • Here is the GNU bug report I referred to above: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49413 – q.undertow Sep 06 '22 at 01:28
  • The bug was in tramp, not magit. – JDS Sep 07 '22 at 12:38
  • That was stupid of me, sorry. Nonetheless the point I was making is valid: this behavior is present with tramp 2.5.2.28.1. – q.undertow Sep 08 '22 at 16:47