Making TRAMP go Brrrr
44 comments
·June 23, 2025julienchastang
I use tramp all day every b/c I mostly work on remote VMs so it is an indispensable tool. Note that tramp will allow you to go inside docker containers on those remote hosts with:
/ssh:<remote host>|docker:<docker container>
Also if you like copying (potentially large) files via dired, consider temporarily
(setq tramp-default-method "rsync")
The blog talks about rsync vs ssh a bit.
imiric
TRAMP is neat, but I find watchexec+rsync to be a much more performant alternative. This way I keep editing files locally, and they're simply synced to the remote host when they change. This workflow also has the benefit of being able to use all my local tooling, it keeps a local copy which I often need, it supports any editor (forgive me, Father rms), and is easily configurable (include or exclude files, delete files on the remote, etc.).
dima55
But then you can't do other stuff. Remote LSP, gdb, etc, etc.
klik99
Nice, I unfortunately need to work on Windows while also doing a lot of remote editing, so switched to emacs on wsl just to use tramp - I wasn't aware of watchexec which seems like a much better solution. However part of what makes tramp great is being able to use emacs just like it's local, so things like ag/magit/etc wouldn't work as smoothly.
wging
I did the same thing when I was building on remote machines frequently. Either an internal one-way syncing tool or Unison, but basically the same as what I think you're implying. (Watchexec to notice changes, and kick off your local rsync to the remote machine, right?)
TRAMP rarely seemed worth it to fiddle with, especially when such a workflow supports all tools, even those run in a CLI outside of emacs: run a formatter or other automation locally and have the changes propagate? git pull locally, ditto? why not?
celeritascelery
> TRAMP rarely seemed worth it to fiddle with, especially when such a workflow supports all tools
The problem is that this workflow doesn't support all tools (or even most tools in my case). The remote machines are a different OS with more RAM and are set up with all the tools and production environments needed. I can't run most of the locally (at least not without massive effort and porting). If you have an environment where you can easily run locally or remotely, then your workflow would make sense.
taeric
I haven't been in a workflow where tramp is useful to me in a while. I recall it was borderline magical back when I did use it. I'm assuming it is highly reliant on how good your network connection is?
Definitely has more config now than I recall. Kudos on benchmarking the different settings here. I'm definitely curious to see what sort of stuff gets tried to make it even more seamless.
thom
Just thought about this for a second and it made me sad: I haven't SSH'd into a machine in at least a couple of years at this point. Everything works through web frontends, git, CI/CD, Terraform etc. Actually editing a file on a server instead of treating everything as amorphous ephemeral compute would be a real guilty pleasure!
lotharcable
Tramp can work better for containers then it does over SSH.
I use it conjunction with distrobox and podman. It should be able to work with kubernetes as well.
SoftTalker
There's very little if any config that is strictly necessary. I used to use TRAMP quite a bit and I never configured anything. Of course like all emacs packages you can config and tweak it to your heart's content.
afr0ck
I use vim with mutagen for syncing files. It's simple and works fine, but you have to duplicate storage.
jonnycomputer
I kinda gave up on using it because so many of my remotes are tunneled through a jump host and I never could get it to connect seamlessly. It seems like it ought to, but when vscode just works with my ssh config, I decided debugging it was not a good use of my time. Might have something to do with being on a Mac, idk.
gray_-_wolf
I found https://www.gnu.org/software/tramp/tramp-emacs.html#Multi_00... to be working pretty well, but it definitely took some fiddling and experimentation to get the right settings.
jonnycomputer
Thanks.
Someday I'll get to fiddling with it again.
jerf
I think that in general, if you're doing anything fancy with SSH, you're better off setting it up in SSH than trying to convince Tramp to do anything with it. See something like https://wiki.gentoo.org/wiki/SSH_jump_host . Basically, the goal is you should be able to type "ssh someSSHConfig" and get to the shell of the device. If you can do that, you don't need to worry about what Tramp can and can't do, and if SSH adds a feature that works in the SSH config you don't even have to wonder if Tramp can use it.
And then it also works with everything else that works with SSH.
aidenn0
I found that setting (customize-set-variable 'tramp-use-connection-share nil) made things "just work" with my .ssh config (the documentation for that variable seems to imply this is expected).
If you still want connection sharing, you'll have to set it in your .ssh config, but it works without it.
rdtsc
That's awesome. Thanks for sharing. I use tramp periodically and had to discover some of those on my own.
> I kept thinking to myself “There has to be a better way to do this”. I have started to think of ways to fundamentally improve the performance of TRAMP that would involve changes to the package itself. I plan to write more on that soon, so stay tuned!
Will look forward to it! TRAMP is really a gem and it does feel like it should be able to go faster. Either with some config tweaks to modernize it a bit, or some improvements in the caching or the sync logic.
dima55
Yeah. Thanks for writing all that up. I use TRAMP heavily, and any performance improvements would be welcome.
Twirrim
https://www.gnu.org/software/tramp/#Overview For details about tramp, in case (like me) you had no idea what tramp is.
shwouchk
tramp is great. all the other mentioned solutions are nowhere near as seamless for “just do what i want, without distractions”.
vscode? “trust me bro, i will run a networked daemon on your server”. enjoy wondering which plugins to reinstall on your remote. enjoy installing proprietary shareware+telemetry plugins just to use git. try opening a local file and a remote file side by side in the same window. wifi connection broke for a sec? oops, you have to refresh the whole browser window.
want to edit a single file on a host you rarely connect to? enjoy spending 10 minutes setting up autosync solutions.
with any of the above - oops, you actually need sudo for that file in /etc? yeah, drop to shell and edit in vim.
there are other options to do stuff and for very specific predefined workflows they may win, but the versatility of tramp is still unmatched, especially if you do use emacs.
the only times ive had issues is when i have a weird shell setup on the remote - for that there is /sshx: instead of /ssh:
IceDane
Tramp is tolerable, but it is absolutely not great. You went on to demonstrate that right after making that claim, where you manually (and insufficiently) hack around its issues to arrive at something that is only barely comparable to eg what vs code can do.
kleiba
Forgive my ignorance, but what does VSCode do?
shadowgovt
Tramp is how I finally got over the chronic problem of having to use vim just for remote editing files on remote machines over an ssh session. It does sometimes hang and chug inconveniently, but dealing with that is far easier than delicately holding a config file like a flower while I remember the precise vim commands (and work around the TTY special code interpretation issues that break arrow keys) to make my edits to one line.
N'ah, forget that. It's worth the setup time to make Tramp go brr.
globular-toast
This is all good advice. TRAMP is really quite good once you figure out what's slowing it down.
I had a problem that was making it hang at times. Of course, Emacs would respond to `C-g` still, though. Toggling `toggle-debug-on-quit` showed me what was causing it to hang. Something from the ESS package which I rarely use anyway, so I just disabled it.
So... people dont's save to local files and then manually ftp them anymore these days? I should check this stuff out