lsp服务慢的时候导致的Emacs输入卡顿问题请教

我有一个1300多行的vue文件,输入的时候vls补全一次大概需要5s,比较了vscode、vim+coc.nvim以及emacs,只有emacs会输了几个字符之后就无法上屏了,只有等补全结果返回之后才有反应,因为 company的补全也声称是异步的,为啥会出现交互卡顿的情况呢??

经测试如果后端秒回的话是不卡的,所以肯定不是 lisp 处理消息慢的问题。

简单对比了一下三个编辑器:

  1. vscode 和 coc.nvim 在输入的时候都是只触发一次补全(具体vscode是不是只触发一次,只是看打印lsp log来推断的),而coc.nvim 的介绍里面是提到了的;

  2. 而emacs的实现是每次触发新的请求都会取消上一个请求,对于这种后端很慢的情况,就成了恶性循环,每次都触发新请求的话,那啥时候也补全不上,而且还会导致后端要连续处理好几个耗时很长的任务。

所以,想问问emacs有类似的方案吗?只触发一次,如果要补全的内容差不多,比如a和ab,ab直接复用a的请求,等请求回来再前端过滤一下直接去补全,实际可能会更负杂,但是持续触发新的请求感觉更影响体验。 另外,再咨询下,company-mode 的异步是使用定时检查来实现的吗,emacs-lisp 貌似也支持 Promise ,好像 company 也没使用这种方式。

我也遇到同样的问题,非常非常卡,楼主有找到解决方案吗?

卡顿的时候,你看下 Emacs 内存占用。如果我理解没错的话,此时你的内存占用会非常高,有可能高达 1.5G。

此时最简单的做法就是完全重启 Emacs

lsp-mode 的实现和性能都太差,看着支持语言很多,整体架构没设计好。

等我下半年有空,基于Python和多线程设计,设计一个新的 lsp-bridge

  1. 对LSP Sever主要做好汇总、容错和性能管控
  2. 对Emacs实现一个支持多后端(不仅仅是LSP,还包括 yas 等)的高性能前端,前端可以用Qt来实现

从高性能的角度来设计整个补全框架,补全一旦卡,支持再多语言都不想用。

15 个赞

同感,大型go项目,gopls 真的卡

=-= 我感觉 gopls 已经算是做的不错的了

Qt作为前端岂不是TUI下用不了了 :joy:

你是多大的项目,我用 gopls 改 Prometheus 代码,比较流畅

我们为什么不用 rust 重写一个呢。

2 个赞

之前讨论过,目前json解析似乎并不是瓶颈了,因为Emacs引入了原生的libjson。

不过到目前为止,我用自己的Centaur配置,还没有遇到楼上说的如此严重的性能问题。日常使用的项目规模也不算小,第三方库也很多,不知道是否与配置有关。

大概率配置问题。说卡又不贴配置的,都是耍流氓😹

和电脑性能关系很大, 我在台式机上感觉一切都很快.

我现在一直用的 doom-emacs ,16G内存的macbook pro,大文件的时候依然会出现卡的情况卡的时候编码体验老差了 :joy: 补全的慢还可以接受,但是补全慢的时候都影响上屏,明显感觉到敲一下字母卡一下才出现,就很难受了 台式机32G体验确实会好不少

啥时候 emacs 的补全体验能达到 vscode 的效果就完美了,用emacs习惯了之后换到vscode、vim,各种适应不了。。。

1 个赞

上面都说了用的Centaur Emacs,搜一搜又不费事儿。贴多了又会有人说做广告啦

https://github.com/seagle0128/.emacs.d/

你好像理解错了,他应该说得是提问者

:rofl: 歪个楼,不嫌弃 ctags 的话可以试试 Citre

1 个赞

我也安这个了 :+1: 前端天天写js/ts/vue/react的那一堆库 lsp 还舍弃不了。。。

对于lsp server反应慢的情况, 可以把company-idle-delay设置大一点试试, 比如1

我不懂前端啊,但是可否试一下把你用的库和工程一起扫描了?ctags 扫描的时候可以添加外部库的路径的。