-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is the first problem still relevant with the new JSON parser? #35
Comments
The new parser is actually very fast and it does not rely in external libraries. So, a new benchmark set could be interesting now in Emacs 30. BTW: I don't totally understand the current benchmarks numbers I see in the Actions. Some of them seems actually confusing. How can I see the speedup difference with and without booster? |
The benchmarks provided are for the artificial case of reading from JSON vs. reading from the equivalent (translated) bytecode. That's related to but not identical to the actual speedup you might get. You can actually run the booster without doing JSON conversion; see |
I ran the included test with an Emacs 30 (emacs-plus on Mac M2) compiled with native-comp and the new native JS parser. Results: % cargo test test_bytecode -- --nocapture
running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 4 filtered out; finished in 0.00s
running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 1 filtered out; finished in 0.00s
running 0 tests test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 1 filtered out; finished in 0.00s
running 1 test test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 21.19s The plist-flavored results are most relevant for eglot. In those tests, bytecode still holds the edge for small messages (4 and 12kB), but at larger message sizes (100kB), native JSON parsing dominates by >2x on my machine. I interpret this to mean that disabling bytecode on Emacs 30 is probably a good idea if you deal with large LSP messages. Give the test a try and report your results. |
Here are my results in an AMD Ryzen 7 5700U with the nixpkgs' emacs-pgtk (30.1):
|
Your results look similar. My guess is that JSON parsing is moderately faster than bytecode parsing once the data are in memory. This makes sense, since ELISP is a more general and complicated syntax. But small messages are dominated by their read time, which has fixed offsets associated with it. Once the parse time exceeds the read time, JSON wins. Since most people's performance problems likely stem from large messages I think disabling bytecode is the right move. I just added some stats tracking to Plenty of 100kB JSON messages, but median size is under 1kB. Probably worth disabling bytecode translation though, as the large messages "cost" more in terms of latency. |
This may be faster for large messages with emacs-30 as described in blahgeek/emacs-lsp-booster#35 The idea is that bytecode parsing might be slower than JSON parsing for large messages. In such a case, just using lsp-booster for IO buffering could be the best bet.
After Emacs 30 introduced a new JSON parser I was wondering if the first problem is still relevant, and how faster the parsing might be.
The text was updated successfully, but these errors were encountered: