tramp为什么这么慢？ 大家一起讨论一下

Emacs-general
1

Emacs不能用高性能浏览器和PDF软件， 现在可以用EAF搞定。

Emacs用同样的 LSP 服务器没有 VSCode 流畅， 现在 lsp-bridge 性能和 VSCode 一样， 甚至多语言比 VSCode 还快。

Emacs最后一个慢的地方是 tramp, 我的理解 tramp 的工作就是一个 SSH 同步程序， Emacs主要是针对 Buffer 内容进行修改， Emacs 保存的时候， tramp 透明的保存到远端， 从原理上不应该这么卡呀？

有哪位同学读过 tramp 的源代码？ 大家一起讨论一下为什么 tramp 那么慢？ 或者除开慢， 大家最喜欢的是 tramp 哪些功能?

讨论清楚了， 我有可能明年有时间会开发一个高性能的远程穿透插件来替换 tramp， 看看顺带能否和 lsp-bridge 协作来实现远程高性能代码补全。

28 个赞
2

看启用了哪些package吧，比如project版本控制自动检测，自动保存，不仅仅是同步buffer内容

1 个赞
3

以前用过一阵子 tramp，嫌慢就放弃了。

.ssh/config 加上这几行应该会有一定程度改善。

Host *
    ServerAliveInterval 30
    ControlMaster auto
    ControlPersist 30m
    ControlPath ~/.ssh/sockets/%r@%h:%p
5

改单个文件还好，用来写项目代码就不行了。

仅仅是project.el打开文件就十分卡

6

盲猜同步运行 scp 在本地于服务器之间同步文件。tramp 和 auto-save 一起基本没法用，一步一卡。

9

是不是因为 ssh 的配置没加？

Host *
    ControlMaster yes
1 个赞
10

（我其实有类似的配置，不过好久没用过 tramp 了，所以不清楚有没有效。）

Host *
    CheckHostIP no
    HashKnownHosts no
    ControlMaster auto
    ControlPath /tmp/ssh-%C-control
    ControlPersist 1d
    ServerAliveInterval 60
1 个赞
11

大佬target 到我特别感兴趣的地方了！关注关注！

12

TRAMP 好像是依赖这个 start-file-process-shell-command 命令 (或者类似的命令) 在远程读文件，根本没有考虑 ssh 复用之类的情况。另外它还有一套自己的缓存机制，我感觉很累赘，根本不能解决速度的问题，反而很可能拖慢了初始连接的速度。我觉得就让 TRAMP 处理一些本机的 (sudo) 或者本地网络的东西，别指望它处理远程的东西，太慢了。很期待新插件！

13

tramp只适合修改单个文件，开project、lsp、flycheck之类的就很慢。

14

lsp可以把lsp server一并放远端。

15

期待！远程开发猿的福音

16

@manateelazycat

请问懒猫，当下可以按照lsp-bridge 远程代码补全这篇帖子实现VSCode中remote development extension插件的功能吗？还是要等之后的远程穿透软件。

17

现在只要服务器有ssh公钥。

你直接使用 lsp-bridge-open-remote-file 以及用户名，ip和路径，lsp-bridge就可以自动穿透到远端服务器自动补全啦，啥都不用做。

我没有太看懂你要问的意思。

18

就是我的emacs安装到本地，远端GPU服务器配置了相应的pytorch环境之类的。

如果使用vscode的remote development插件，可以ssh连到服务器编辑、运行代码，浏览服务器文件。

想请问现在的lsp-bridge可以实现上述内容吗？谢谢！

19

远程编辑文件和远程补全已经实现了。

远程运行命令目前可以通过emacs一系列终端插件配合使用。

远程浏览文件的功能还没开发，主要最近太忙了，可以去github提issue

1 个赞
20

这功能我也感兴趣 先插个眼吧

  1. 编辑单个文件 的时候 得要记得目标机器的文件路径 (这个也挺烦的)
  2. 就是慢 保存卡一下
21

lsp-bridge现在已经不需要tramp支持远程文件实时编辑，保存和代码补全了，不会卡哪怕1毫秒。