Might emacs-lsp-booster offer additional performance improvements?

[phil-s]

https://github.com/blahgeek/emacs-lsp-booster is very interesting. It seems to provide an intermediate rust-based service which reads the JSON from the LSP server and outputs equivalent emacs lisp byte-code data for the LSP client in Emacs to read instead of the JSON.

Given that Emacs nowadays has the libjansson C module for reading JSON into lisp objects, I'm pretty startled by the benchmark results they've mentioned: Apparently Emacs is reading the byte-code data in a quarter of the time that it takes to read the JSON data.

I'm curious as to whether that technique could benefit lsp-bridge as well?

[manateelazycat]

The technology of lsp-bridge is much more advanced than this. Thanks for the suggestion.

[manateelazycat]

I belive emacs-lsp-booster use same tech as lsp-bridge, lsp-bridge is build middle-server between emacs and lsp server.

[manateelazycat]

But lsp-bridge build-in multi-thread tech for backend, lsp-bridge not just improvement lsp performance, all acm backend is rebuild with multi-thread tech.

[phil-s]

I was just wondering whether the specific technique of providing Emacs with readable byte-code data instead of JSON might be something that lsp-bridge could also do for a similar benefit. (If lsp-bridge never asks Emacs to parse JSON then my question isn't relevant.)

I have very little understanding of lsp-bridge, sorry. I don't use it myself*, and I do understand that lsp-bridge and emacs-lsp-booster are very different projects, but I thought it was possible that this particular trick used by emacs-lsp-booster might be of interest here as well.

* I've never had much success with the language servers I've tried in the past, so I don't use LSP.

[manateelazycat]

lsp-bridge return sexp result to Emacs, lsp-bridge use Python or Rust parse JSON data.

I don't think byte-code will improve Emacs performance, because some lsp server will return 50,000 lines JSON to emacs per key click, data is too big that Elisp haven't enough performance to handle it, because Elisp is single-thread, it will block Emacs if too much data need to parse.

lsp-bridge is first project to make Emacs LSP performance fast as VSCode, I belive author of lsp-mode or emacs-lsp-booster steal idea from lsp-bridge. Note, I think other project steal idea from lsp-bridge is good thing, it's why Open Source is great thing. ;)

[phil-s]

In that case the only point of interest for you might be this:

By using bytecode to construct objects, we can eliminate duplicated objects

-- quoted from https://github.com/blahgeek/emacs-lsp-booster#how-this-project-works

If that's a common situation, then using byte code for the sexp forms rather than the original lisp forms may provide an additional benefit to what you're already doing.

Either way, I'll leave it in your capable hands. Thanks for the quick responses!

[manateelazycat]

The key to the problem is that LSP has a large amount of data. If external threads are not used for filtering, no matter what format, too much data will cause performance problems and GC startup. The reason is that a large amount of data exceeds the processing capacity of Emacs. The lack of multi-threading in Emacs is the root cause. .

No matter what format is used, even if the performance is improved, as long as the amount of data reaches a certain level, freezing problems will still occur.