Could the readme provide a brief comparison with lsp-bridge?
Opened this issue · 2 comments
https://github.com/manateelazycat/lsp-bridge is another external service for speeding up LSP in Emacs.
(Or rather, it is a whole separate LSP client -- ala eglot or lsp-mode -- but one which utilises its own external services for performance purposes.)
It would be great if the documentation provided a brief comparison of the similarities and differences, and it would be really useful to know how the performance of lsp-bridge compared to the performance of both eglot and lsp-mode when enhanced by emacs-lsp-booster.
I'm also curious as to whether the method used for emacs-lsp-booster might be used to provide further performance improvements for lsp-bridge. The latter seems to be written in python rather than rust, but I presume the technique could be ported even if the rust code can't easily be used more directly.
Edit: I've since queried that last part directly in the lsp-bridge issue queue at manateelazycat/lsp-bridge#824
lsp-bridge is a full LSP client in Emacs (and Python), one which entirely replaces lsp-mode and eglot. This booster simply makes those clients' jobs easier by making the underlying lsp server i) more responsive, and ii) speak in elisp bytecode, which is ~4x faster for emacs to parse than JSON. So all of the normal built-in or 3rd party completion, xref, etc. tooling work exactly the same as before (just faster and with less I/O blocking).
I am not an lsp-bridge user, but my understanding is that it is similar in spirit but goes much further to try to optimize things like completion, for example allowing emacs to interrupt the bridge so it doesn't bother sending expired data which will just be ignored. I'm not sure if it translates JSON into bytecode or list literals, but it does appear to do advanced caching to avoid I/O contention, similar to this simple booster. It is a "smart bridge" which to some degree speaks the LSP language and communicates on its own with the lsp server, and it utilizes that capability to optimize the flow of traffic between (its own) emacs client and the lsp server. Think lsp-bridge = "negotiator" vs. lsp-booster = "translator".
It's true that the "bridge" in lsp-bridge is a python program, whereas this one is built on rust. And unlike rust, Python does not have true parallel threading (yet!), but I truly doubt that makes any difference, since most all the operations between server and client are I/O bound. So I think that distinction can be ignored.
The cost of lsp-bridge's functionality is that to achieve its goals, it had to implement its own non-standard, standalone "world", with its own completion system, completion UI, auxiliary completion backends, xref functionality, language server support, requirement for no native compilation, etc. By all appearances it is a highly functional and performant world (e.g. it's dabbrev completion equivalent I understand runs circles around dabbrev). But you have to stay in that world for all lsp-related activity, and use different tools and UIs outside of it.
There's also a maintenance difference. If both tools stopped being maintained today (not that that is likely or imminent), I suspect this simple booster (~1k lines of code) would continue to function just fine for 5 or 10 years, whereas lsp-bridge (~20k LOC, not counting epc) would suffer more from that lack of maintenance.
I recommend trying them both to decide which has the features and tradeoffs that work for you, after first seeing whether lsp-mode or eglot are sufficient on their own.
LSP-bridge not only increases JSON parsing speed but also uses Python multi-threading to encapsulate all time-consuming LSP-related calculations in a separate Python process. This avoids any lag caused by large data computations (such as the Volar server). If you only accelerate JSON parsing without encapsulating other logic into subthreads, you can only reduce lag, not avoid it like LSP-bridge does.
JSON parsing in LSP-bridge can optionally use the orjson library, which is implemented in Rust and achieves the fastest parsing speed possible.
The maintenance cost of LSP-bridge is not an issue. Even in terms of code volume, LSP-bridge should be much smaller than LSP-mode + emacs-LSP-booster + company/corfu combined. The advantage of LSP-bridge is that if there's a problem, whether in the completion frontend or backend, it can be fixed from the fundamental level. Users don't need to integrate and configure these details themselves. In simple terms, LSP-bridge has the advantage of being out-of-the-box in this aspect.