也挺好：Emacs LSP performance booster

Programming
1

Improve the performance of lsp-mode or eglot using a wrapper executable.

13 个赞
2

感觉有点意思，Windows上自己编译，配合大佬给的 eglot-booster.el 可以使用。效果上，感觉是快了，但怀疑有点心理作用的因素，再用一段时间试试。

1 个赞
3

这个项目的优点：

  1. 通过Rust外部进程解析LSP JSON， 避免Elisp直接解析LSP JSON， 会提高一部分性能

待考查的缺点：

  1. 把大量 LSP JSON 变成 Elisp Byte Code， 数据量太大还是会导致 Elisp 解析 Byte Code 对象也会性能遇到瓶颈和GC阻塞
  2. 不在外部进程缓存诊断对象， 实时把上千个诊断对象返回Elisp创建Overlay也会遇到性能瓶颈

彻底解决性能瓶颈不仅仅是要减少解析对象的过程， 本质是要引入多线程机制， 并且减少对Emacs端发送不必要的对象（比如上千的诊断和上万的API文档等等）， 最大程度减少Elisp计算的对象并且在前端要减少上千个候选词过滤，才能彻底解决性能问题。

4 个赞
4

也不奢求能彻底解决了，个人而言，性能有提升，对现有配置侵入少，能很方便的整合进现有的配置就值得 star 了。

9 个赞
5

试用了一段，性能基本满意，搭配elgot-booster设置也很简单。已经集成进Centaur。

1 个赞
6

jdtsmith 评价的蛮中肯的

2 个赞
7

我加了一段评论：

lsp-bridge不仅仅是增加 JSON 的解析速度，而且是通过Python多线程把 LSP 相关的耗时计算都封锁在 Python 独立进程中， 避免任何大数据计算 (比如 volar 服务器）导致的卡顿， 如果只是单纯的加速 JSON 解析， 而不把其他逻辑封装到子线程中， 只能减轻卡顿， 而不能像 lsp-bridge 那样避免卡顿。

lsp-bridge 的 JSON 解析可以选装 orjson 这个库， orjson 这个库使用 rust来实现的， 性能上已经达到最快的解析速度了。

lsp-bridge的维护代价并不会有问题， 即使从代码量来说， lsp-bridge 应该要比 lsp-mode + emacs-lsp-booster + company/corfu 代码量要小很多， lsp-bridge 的优势是， 万一有问题， 不管是补全前端还是补全后端， 都可以从原理上修复， 用户不用自己去融合和配置这些细节， 简单来说 lsp-bridge 这方面具备开箱即用的优点。

7 个赞