Eglot 的一个关于性能的小问题(或许算是一个分享)……

Eglot 时候觉得有些一顿一顿的,今天尝试着用 profiler 定位了一下,发现性能的很大一部分消耗在了 jsonrpc--log-event 上。额,就觉得吧,一般用户实际上也用不上这个不是,就尝试着进行了一下 advice,感觉整个体验都起飞了,好像没看到有人提过这个问题,我这里提一下,代码如下,希望对大家有所帮助,使用 use-package 的话,放在 :config 后面就行了

(advice-add 'jsonrpc--log-event :around
              (lambda (_orig-func &rest _)))

PS:我试着在 github 里搜索了一下,居然好像有人提过 issue:

3 个赞

好像人家直接支持关闭event buffer

 (setq eglot-events-buffer-size 0)
7 个赞

对,是我疏忽了,刚刚点到那个 issue 里看到详细的讨论了,我说怎么论坛里没有看到人讨论呢

可以可以,之前确实想把这个关了,最近忘了

:+1: 关了这个选项以后, *EGLOT events* buffer 小很多了,原来在 clangd 下刚启动就 134K,现在只有1.2 k。

感觉是个 bug,eglot-events-buffer-size 设置为了0,但还是会增大,只是比较慢。设置为 1,就彻底没消息了。

5 个赞

设置完重新启动下 Emacs呢?我这边 eglot-events-buffer-size 设置为 0 后,eglot 是不会生成 *EGLOT events* 这个 buffer的。

重启过了,我用的是eglot最新的commit,查看 eglot-events-buffer-size 这个变量确实是0,而且 EGLOT events 的信息少了很多。

启动 eglot (clangd)的时候会有这些信息:

[stderr] I[09:11:38.996] Apple clangd version 13.1.6 (clang-1316.0.21.2.3)
[stderr] I[09:11:38.997] Features: mac+xpc
[stderr] I[09:11:38.997] PID: 17457
[stderr] I[09:11:38.997] Working directory: /Users/eason/Code/Cpp
[stderr] I[09:11:38.997] argv[0]: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clangd
[stderr] I[09:11:38.997] Starting LSP over stdin/stdout
[stderr] I[09:11:38.997] <-- initialize(1)
[stderr] I[09:11:39.002] --> reply:initialize(1) 4 ms
[stderr] I[09:11:39.003] <-- initialized
[stderr] I[09:11:39.004] <-- textDocument/didOpen
[stderr] I[09:11:39.005] Failed to find compilation database for /Users/eason/code/Cpp/test2.cpp
[stderr] I[09:11:39.005] ASTWorker building file /Users/eason/code/Cpp/test2.cpp version 0 with command clangd fallback
[stderr] [/Users/eason/code/Cpp]
[stderr] /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang /Users/eason/code/Cpp/test2.cpp -resource-dir=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.1.6
[stderr] I[09:11:39.016] <-- workspace/didChangeConfiguration
[stderr] I[09:11:39.538] <-- textDocument/signatureHelp(2)
[stderr] I[09:11:39.538] <-- textDocument/hover(3)
[stderr] I[09:11:39.538] <-- textDocument/documentHighlight(4)
[stderr] I[09:11:39.570] --> reply:textDocument/signatureHelp(2) 31 ms
[stderr] I[09:11:39.581] --> textDocument/publishDiagnostics
[stderr] I[09:11:39.581] --> reply:textDocument/hover(3) 43 ms
[stderr] I[09:11:39.581] --> reply:textDocument/documentHighlight(4) 43 ms

确实挺奇怪的, js 那边是直接消失了,C 这边依旧会启动一个 buffer

2022-05-21 09-21-58屏幕截图

看来还是得 advice,一劳永逸,哈哈哈……

你可以给 Eglot 报个 issue 吧 :grinning_face_with_smiling_eyes:

目前这个变量跟它文档说明描述的都不一致。

我英语渣啊,能看不能说的那种。

不过设置为 1 能解决,就先将就了。就是多了个空 buffer

我在上面的那个讨论中回复了一下,先问问是不是bug。Elogt 的 bug 列表已经够长了 :grinning_face_with_smiling_eyes:

1 个赞

我也试了下其他语言比如 cssjavaLua都成功关了(没有生成 buffer),目前来看就 C 那边会生成(我用的 ccls 也一样)。或许应该顺道说一下?

lsp这玩意简直是 issue ddos

3 个赞

已经加上了。

1 个赞

确实是,这么多后端,而且后端的实现中也可能有 bug, 都往 lsp 客户端报。

太形象了 :rofl:

大佬,用我写的lsp-bridge呀,速度超级快

1 个赞

不敢当 :rofl: 不了不了,不太喜欢 lsp