Making TRAMP faster | Hacker News Reader

Making TRAMP faster

coredumped.dev

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.

I don't understand what the blog post meant that rsync breaks the remote shell. Do you know what the author means? When would one want to use rsync and when scp?

> When would one want to use rsync and when scp?

When moving large files.

> Do you know what the author means?

I am not sure, but I think you want ssh most of the time except when moving large files.

I filed a bug report on that, and it is going to be fixed in the next Emacs release

https://lists.gnu.org/r/tramp-devel/2025-06/msg00001.html

It really changed my workflow with embedded linux stuff, like openwrt or raspberry pi. Instead of installing an editor on the remote system, you can use emacs on your powerful system and edit things like config files easily in a lightweight way.

Also, using persistent ssh connections makes a huge difference, esp. if you’ve got a heavy shell init on the local or remote side

  Host *
      ControlPath ~/.ssh/cm-%r@%h:%p
      ControlMaster auto
      ControlPersist 600

Isn't recent Tramp versions using this by default?

I thought TRAMP overrides that setting in your SSH config.

> TRAMP uses the ControlMaster=auto OpenSSH option by default, if possible. However, it overwrites ControlPath settings when initiating ssh sessions. TRAMP does this to fend off a stall if a master session opened outside the Emacs session is no longer open. That is why TRAMP prompts for the password again even if there is an ssh already open.

https://www.gnu.org/software/emacs/manual/html_node/tramp/Ss...

It does and it becomes a bit annoying if you were already persisting sessions, but you can just tell emacs to use the same sockets that ssh sets up.

It's a good optimization, but be careful with it since it's not 100% compatible with the normal behavior. A master connection (the first one you establish) will not be able to close until all other connections have done so. Not all software can handle this correctly.

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.

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.

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!

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.

It recently gained native support for nspawn containers too (that used to require a third-party package)

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.

The async process sounds promising but unfortunately eglot doesn't work with it. I got a message from reddit that tramp 2.8.0-pre has fixed that issue but until last time I compiled HEAD from tramp repo it still doesn't work.

I just applied other configurations from the article and it seems faster than the default settings. Thank you author for sharing this!

https://www.gnu.org/software/tramp/#Overview For details about tramp, in case (like me) you had no idea what tramp is.

For those not into the lingo, Tramp is the Emacs module/package responsible for allowing you to transparently work on remote files and host in your local editor in a way I haven’t seen any other software do.

And yes, it’s really neat.

Thank you. I don’t know why more posts like this don’t spend a line or two providing that context

Because the author had no particular expectation this would be a #1 hit on HN.

So, here's the first three sentences in the linked article:

I recently changed jobs and found myself in a position where I would need to do a lot of work on remote machines. Since I am Emacs user, the most common way to do this is using TRAMP (Transparent Remote access, Multiple Protcol). TRAMP is an Emacs package that let’s you treat a remote host like a local system, similar to VSCode Remote Development Extension.

Doesn't that provide context?

To be fair, I added that after reading the parent comment. I did a poor job of describing what TRAMP was because I targeting this towards Emacs users.

Ah! That explains my confusion. Thanks for clarifying, and my apologies to sylens.

Great post, by the way!

> in a way I haven’t seen any other software do.

It was novel once upon a time, but almost every internetworked operating system supports network-transparent files. Even my iPhone can do it.

Linux is a bit weird though: VIM has netrw which is very similar to Emacs; Gnome has a special VFS API that understands URIs, but only in the loosest possible sense of the word, and it can't work with autofs to "un-URI" something into a regular unix path, which is just sad.

But if you don't care about that, autofs can make it possible to cd /net/{hostname} and get my home directory over ssh on another machine, and works much better than tramp IMO, even under Emacs.

The thing is TRAMP also gives you a shell, not just a file access. When I am in a remote buffer, I can do M-x shell, and I will get a command line running on the remote host. What is more, since the T stands for Transparent, when I want to insert e.g. output of some command into a buffer, the command is executed on the remote host and I do not have to do anything special to achieve that, it just happens auto-magically based on the directory of current file (local vs. remote). I find that useful, and you cannot really do these things with a network drive on Windows.

It's not only about transparent access. It's about how the whole emacs ecosystem working with the files. So you can bookmark a remote file, and once accessed, you can launch dired (the file manager) for the file's directory, run the shell on the remote,... with the same binding and mechanism you have for local files. No need to alter configuration or launch a special windows for the project.

I’ve been using emacs for many years and I had no idea you can bookmark files let alone bookmark remote files! Thanks for educating me today!

It's a neat feature. I typically bookmark directories on remote hosts, project roots, config files, etc,.. BTW, you can use `list-bookmarks` then annotate each bookmark with `e`, and display all the annotations with `A`.

Exactly this, it's hard to explain to a non-emacs user why TRAMP is so magical, but the number of times I tried to run something that was meant to run locally on my machine through TRAMP and it just worked is very impressive. It runs so smoothly that you forget you're executing things on a remote machine, and when that leaks through it's typically very easy to diagnose and fix - for instance I have ag (silver searcher) installed on my local machine, tried running a search with ag via tramp and the bin obviously wasn't on the remote machine, a simple apt-get later and I could run my search with all my custom settings remotely.

If anyones ever used the Plan 9 OS across network, TRAMP is like that for emacs

It is a very special piece of work. The closest I've seen is vscode remote editing (and credit where it's due: vscode remote editing is out of the box far more reliable and stable than Tramp... it better be, since it's running its own daemon on the remote machine), but Tramp is far more general-purpose than vscode's solution.

Editing as another user, editing a remote file, even editing over embedded protocols like adb: Tramp's got you covered.

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:

What about mounting a remote file system over sftp? Install EMACS or whatever editor you prefer on the remote?

> What about mounting a remote file system over sftp?

That can be OK for some tasks, but not others. For example, TRAMP will execute commands on the remote; so commands like M-x find-grep-dired will be faster when using TRAMP.

> Install EMACS or whatever editor you prefer on the remote?

There's actually a lot of flexibility there, since Emacs is perfectly usable in a text terminal, which could be run over SSH; it can also show X11 windows over the network (though I recommend the "lucid" build, rather than GTK); and it also has a client/server mode.

installing an editor on the remote sure works - my mention of vim was not an accident, it is my preferred remote editor. some of us are bitextual ;-) - but then you lose the seamless remote+local editing, need to sync your config, potentially clash with someone else’s (ever ssh into ubuntu@awshost?), take special care not to sync any private stuff, etc.

as for sftp, unfortunately that’s not an option if you happen to use windows locally eg for work reasons, nor if you use a mac as of several years now, since fuse became closed source.

not to mention, again, the fact that you are limited to whatever root you decided to mount, limited to editing as a user that i’ve already mentioned, as well as limited from using remote tools as sibling stated. try making a git commit over sftp.

if you have a focused “working on a project” workflow it may work, otherwise PITA

I suppose I fail to see the advantages because I have never had a need to keep remote and local synced as I go. Its always been work on local and sync to remote, with editing on a remote for very specific and limited things.

i was replying to “install your preferred editor on the remote” - without syncing your config, you might as well just use vim even if it’s not your favorite.

most of my remote editing fits into your description. of course, if you’re not an emacs user, you likely won’t find much value in tramp, magit, org-mode, dired, ediff, eshell, etc

Not sure how you can compare vscode with TRAMP. A lot of dev work nowdays is done in containers where you install specific versions of dev tools, compilers, etc. Vscode is one click from seamlessly working inside such a container with its dev tools. TRAMP doesn't provide anything like that, right?

Of course, you can use TRAMP to edit files inside docker containers. You don’t even need to install anything inside them.

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.

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.

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.

Thanks.

Someday I'll get to fiddling with it again.

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.

I'll give that a try maybe.

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.

Oh I have .ssh/config like:

    Host vm3
    User myusername
    HostName the-host-name
    ProxyCommand ssh -W %h:%p myusername@jump.host.address

So will jump through automatically using my ssh keys. Its very convenient. But Tramp doesn't seem to respect that configuration, or demands that I use a password instead of the ssh keys (its been awhile since I've last tried, so I kinda am dim on the details of what was the hassle)

Actually I just tried it and it worked like a charm. I used ssh:myusername@vm3, I wonder if I was trying a different protocol before? bit confused what might have changed tbh

That makes sense. I wasn't sure where to go after that because it has always just worked for me. You can also embed your username into the config, FWIW, making it just "/ssh:vm3:".

ISTR ProxyJump is in some way better than ProxyCommand btw.

You can jump through bastion hosts transparently™ with ~/ssh:you_but_jumping@bastion|ssh:you@remote:path/to/file~ (https://stackoverflow.com/a/16408592)

The thing that I had to fiddle with, was getting ssh and tramp to use the same ControlPath to share sockets because it helped make things smooth if you had setup ssh to use ssh-agent and persist connections already.

But yeah, I get why just giving up on tramp has been easier over the years. Besides connecting there's also annoyances on spotty internet that make avoiding it usually a better experience. I think I haven't relied much on tramp after trying to use it and realising tmux+emacs was overall better at the time, mainly because I could just hop on my workstation to the exact same session I was using once RTO happened. Nowadays I use it mostly for sudo and one off things, but not remote projects with remote compile and lsp anymore.

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.

Yeah. Thanks for writing all that up. I use TRAMP heavily, and any performance improvements would be welcome.

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.).

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?

> 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.

That's exactly the point of remote syncing: whatever changes to code you make locally are nearly instantly available on a remote machine, so you can compile and run your software on a production-like machine. By "supports all tools" I mean that you can run whatever you like on your source code locally, whether it runs through emacs or not, and the result is available remotely. And with bidirectional syncing the reverse is true too.

But I cannot use the remote clangd for LSP, for example.

Right, I suppose it depends on your use case. For most of mine, my local machine has all the tooling, and I simply want to sync the files to a remote machine for deployment. But if you want to do all development remotely, then TRAMP might be the way to go.

> such a workflow supports all tools

Well, it doesn't support anything that we want to actually run on the remote. TRAMP isn't just about files: M-! in a TRAMP buffer will execute the command on the remote; M-x shell will start a shell-mode session that's running on the remote; and so on.

Also, TRAMP remotes don't need to be other machines; e.g. the `sudo` remote lets us open local files with sudo permissions. It's nice to use the same mostly-transparent approach to access other machines, other users, containers, etc.

Also, multi-hop remotes would be more painful to manage without TRAMP, e.g. Emacs will open a path like `/ssh:bastion|ssh:other-machine|sudo:/etc/foo` will open an SSH connection to `bastion`, and from there will open an SSH connection to `other-machine`, and on there will open the file `/etc/foo` using sudo privileges. Again, all the TRAMP goodies like M-! will work as they normally do :)

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.

But then you can't do other stuff. Remote LSP, gdb, etc, etc.

What the OP presumably means is that they just have a local copy of all the files. Then you only edit local (with LSP, gdb, etc.) and any change you make to a local file is mirrored back to the remote copy automagically.

This won't work for things that use a docker container without wrapper scripts, but those have their own problems.

Which means you can’t remote LSP, gdb, etc.

In other words, it only works if your local platform is the same (or compatible) with the remote platform, or (in a limited capacity) if you have a viable cross compiling environment.

watchexec looks like exactly what I was looking for recently. Thanks for this.

lsyncd could be another alternative to that:

https://github.com/axkibe/lsyncd

So... people dont's save to local files and then manually ftp them anymore these days? I should check this stuff out

I used to use TRAMP but now I just run terminal emacs through mosh. Everything just work and snappy, if you can live without the emacs GUI.

This is the way for developing in a remote computer. Alternatively one could start an emacs as daemon on remote and use regular ssh.

For quick file transfer/check, it is faster with Tramp.

I use vim with mutagen for syncing files. It's simple and works fine, but you have to duplicate storage.

GNU's needs something like this too. It's glacial slow even with an SLRN cache.

every few years, less often now, I see an article that gets me excited about tramp, and I try it and immediately deadlock my whole emacs because the remote shell had an unexpected character in the prompt or something.

use sshx remote

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.

Forgive my ignorance, but what does VSCode do?

Download a copy of itself onto the remote, run it there, and allow interaction with that copy

Editing a remote file is very common. Wanting to download and run a remote server every time you edit a remote file is far less common.

E.g. editing a config on an embedded device such as a router, editing a file inside a docker container, editing a file on a headless server, etc etc.

The only reasonable use case I can see for the vscode approach is if you're SSHing into your main development machine from another machine.

The remote server requirements include

> 1 GB RAM is required for remote hosts, but at least 2 GB RAM and a 2-core CPU is recommended.

That's pretty far from the SSH+vi use case that TRAMP replaces.

Correct. I didn't say it was a good thing :)

FWIW it is a one-time download on the remote, but still feels yucky, esp. for resource constrained settings (Pi like you mentioned, but also quota-limited containers etc.)

> Correct. I didn't say it was a good thing :)

Fair enough :)

The typical web dev won't care though, and go ahead downloading and installing a telemetry encumbered server onto the remote machine. All they need is the justification: "But it works!"

DevOps can tell them no all day long, they'll think they know better and give in to convenience over security every time.

What one could do is to block the download of VS Code on all infrastructure.

Emacs can run as a server, and you can connect multiple local clients to it. I've tried various ways to have an emacs client connect to a remote emacs server (forwarding a socket over ssh, etc.) but never gotten it to work so there must be more to it than just the socket.

No, emacs in server-mode does not do what you'd expect. It is only useful to accelerate local start-up. Nothing to do with remote operations.

But it does run in terminal mode - I used to ssh into a remote machine and just run emacs in a terminal there. Actually, there was also some `screen' in the mix, but you get the idea. I preferred that over TRAMP because of the speed.

No I don't get the idea. I was disabusing people of the widely believed myth that an emacs server instance could host remote connections. That one can ssh into a remote machine and run emacs in tty mode is manifestly obvious.

To you, certainly, but perhaps not to everyone. And it can be a good third option in addition to TRAMP or "what vs code does".

I think it doesn't work over tcp but try with the other GUI library.

To be fair, for some dev workflows, TRAMP is lacking (LSPs), but it's more than enough if you're fine with grepping and ctags, I think. For the former scenario, I either run terminal emacs or use distrobox/toolbox (they setup everything for the wayland socket that graphical emacs needs)

LSPs should work fine with TRAMP. In practice I have a problem with it, since there is some bad interaction between eglot, TRAMP, and clangd in certain cases, but that is a specific situation and a bug.

gopls was a bit of a pain. By default it uses stdio, and there were some integration issues with eglot, tramp, amd gopls. I also had some issues trying to use tcp ports. I switched to terminal emacs over ssh, the. use distrobox (I didn’t want to install dev tools locally).

I have just launched a new website, https://www.threenh.com/. I also use this approach: TRAMP defaults to the ControlMaster=auto OpenSSH option, but it will override the ControlPath setting when starting an SSH session. TRAMP does this to avoid lag when the master session opened outside the Emacs session is no longer active. This is why TRAMP prompts for a password again even if an SSH connection has already been established.

something i noticed while debugging tramp perf half the lag isn't tramp, it's elisp codepaths calling sync ops assuming they're cheap. i saw vc-git-root firing on every bufferlist switch because some mode wants to update a badge or refresh a modeline. none of it's aware that the path is remote

That's exactly it. TRAMP itself works fine, but some packages that are only tested on local machines use a bunch of shell calls that are not really needed (i.e. They could cache the result).

A lot of times with emacs you can disable the modeline and get performance improvements because frequent updates happen and arent cached.

Well behaved mode line items typically update a variable periodically so blocking never happens.

Nice and all, but what about the lessons we learned about running development as local as possible, eliminating the need for remote system access. all that sounds very 90's - 10s. These days you have a local environment that can emulate anything (see docker). Then you write code that interacts with that "anything" basically locally. When you are done with the code you can test and deploy - there is no need for remote access.

VMs should not be ssh'd into anymore - they should just be stamped over with the latest code drop. I mean did we not learn anything from the entire devops/ci/cd/immutability lessons of the last 10 years?

If you’re a web developer, sure.

What if my desktop is in the cloud ?

Tramp is an absolute garbage implementation (yeah, its author is just a terrible, sophomoric programmer) of the most naive mechanism you could imagine: bring the file over, edit it, copy it back. "celeritascelery" is genuinely better off using vim and git remotely, his hard-on for magit notwithstanding.

TRAMPs goal is to be able to use ssh, scp, sftp, rsync etc., without any special TRAMP support on the remote side.

Making tramp go brr by removing half of features

Sad to see it's still so far from vscode. Is there really no way to make emacs magically work like vscode without modifying packages

Idk maybe invent something like jit-compilation but for remote/local code. Profile rtt latency then somehow dynamically calculate optimal local-remote code split and transfer remote part to remote machine

There is inherent limitation of latency/responsiveness in the tramp model versus the copy vscode server to my server and communicate with it model.

The tramp model does have the advantage of little to no resource usage, but these days most aren't concerned about that.

Indeed in many cases now the server has more resources than the client accessing it (the "thin client + remote dev box" model)

Reply on news.ycombinator.com