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?

Improve this question
5
  • I don't see this. Does it happen in emacs -Q? Does it happen when you try to connect with ssh manually?
    – PythonNut
    Commented Sep 10, 2015 at 2: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
    Commented Sep 10, 2015 at 3: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
    Commented Sep 10, 2015 at 7:27
  • The first thing I do is set process-connection-type to nil and watch for any relevant bugs here.
    – Emacs User
    Commented Sep 11, 2015 at 1:16
  • For me, tramp-cleanup-all-connections and tramp-cleanup-all-buffers made a difference.
    – Peter Becich
    Commented Apr 6, 2023 at 3:18

3 Answers 3

Reset to default
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.

Improve this answer
2
  • 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
    Commented Nov 25, 2019 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
    Commented Nov 29, 2019 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.

Improve this answer
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.

Improve this answer
4
  • 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
    Commented Aug 26, 2022 at 19:48
  • Here is the GNU bug report I referred to above: debbugs.gnu.org/cgi/bugreport.cgi?bug=49413
    – q.undertow
    Commented Sep 6, 2022 at 1:28
  • The bug was in tramp, not magit.
    – JDS
    Commented Sep 7, 2022 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
    Commented Sep 8, 2022 at 16:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.