Winston Carlile via "Emacs development discussions." writes: Hi Winston, > As a heavy TRAMP user I have been frustrated the past few > years with slowness, and painstakingly looked for ways to > remedy this. Along the way I started to explore Emacs' core > file API and with it the magic filename system, specifically > tramp-sh.el. I quickly came to realize its complexity and > the inadequacy of the Emacs Lisp Profiler in a highly > recursive and interconnected codebase. It is highly appreciated to work on this. However, don't expect that it will help much in Tramp optimization. In my experience, most time in Tramp is spent on wire. That is, sending commands to the remote shell, and reading the command's output. Compared with this, time spent in Elisp is not so important (although any optimization will be appreciated as well). In Tramp it is hard to compare the spent time. Mainly, due to different network latency in different environments. And this can change even in your local LAN over the day, so that you cannot be sure whether an applied optimization helps, or not. I know what I'm speaking about, because I'm working in this area the last weeks. What I use for Tramp optimization is to count the number of commands send to the remote host. The less commands are sent, the better. As a poor man's approach I trace the Tramp functions tramp-send-command (all commands sent to the remote shell go through this) and tramp-file-name-handler (all invocations of Tramp functionality pass this function). The latter is to know, what Emacs primitive function has caused a remote command. So I test something like this (let ((remote-file-name-inhibit-cache t)) ;; Do not use file caches. (trace-function-background 'tramp-send-command) (trace-function-background 'tramp-file-name-handler) (ignore-errors (kill-buffer trace-buffer)) ;; The test. (with-temp-buffer (insert-file-contents "/ssh::.emacs" nil 100 nil))) The *trace-output* for this example is appended. See also the discussion in bug#56342. Best regards, Michael.