3 ms·

> When I configure company to trigger instantly on a single keystroke, Emacs completely locks up pretty much every time I hit a key. Emacs using an elisp JSON

> When I configure company to trigger instantly on a single keystroke, Emacs completely locks up pretty much every time I hit a key. Emacs using an elisp JSON parser is about 15x slower (!) than using a native JSON parsing lib. It's borderline criminal (just kidding): I think LSP should simply test if native JSON parsing is avail and refuse to run if it isn't. I'm using LSP-mode and it flies (AMD 3700X / 32 GB of RAM / Emacs native compilation branch / native JSON parsing). Apparently LSP-bridge is even faster so I may try it but if "Emacs completely locks up" when you hit a key due to lsp-mode, there's an issue (and a solution).

jpe90 4y ago
I'm also on an AMD 3700X, 32G of RAM, with Emacs native compilation branch. I'm totally unaware of elisp vs native JSON parsing though, I was just using stock Eglot that came bundled with Emacs.
- NoGravitas 4y ago
  It's more a question of where you got your Emacs. Native compilation, native JSON parsing, and a bunch of other things are configure-time options.
  - jpe90 4y ago
    Oh I see, I build from source but I’ve been using the same configure options forever (just native comp and rename the ctags binary). I’ll look them over again.
    - hvis 4y ago
      Check that you have `libjansson-dev` installed, or whatever is the equivalent on your system.
      - jpe90 4y ago
        Looks like I’ve got that on my machine, and I built Emacs —with-json this time. Performance is still better but it’s still stuttery. I guess it’s related to either the json parsing happening on the main thread and/or the LSP servers using company-capf which I think is a synchronous backend? It seems like coc.nvim, lsp bridge, kak-lsp, and other editor solution’s i’ve come across all opt to use sidecar processes that manage lsp. Perhaps Elisp isn’t the right tool for that backend processing.
        deagle50 4y ago
        This can be spun off into another thread. I haven't tried it yet but the feedback has been excellent. https://reddit.com/r/emacs/comments/ymrkyn/async_nonblocking_jsonrpc_or_lsp_performance/ https://reddit.com/r/emacs/comments/ymrkyn/async_nonblocking...
        jpe90 4y ago
        Oh what a great idea! I hope this can get mainlined someday(perhaps behind a config option) since Eglot should benefit from that approach as well!

jpe90 4y ago

I'm also on an AMD 3700X, 32G of RAM, with Emacs native compilation branch. I'm totally unaware of elisp vs native JSON parsing though, I was just using stock Eglot that came bundled with Emacs.

NoGravitas 4y ago
It's more a question of where you got your Emacs. Native compilation, native JSON parsing, and a bunch of other things are configure-time options.
- jpe90 4y ago
  Oh I see, I build from source but I’ve been using the same configure options forever (just native comp and rename the ctags binary). I’ll look them over again.
  - hvis 4y ago
    Check that you have `libjansson-dev` installed, or whatever is the equivalent on your system.
    - jpe90 4y ago
      Looks like I’ve got that on my machine, and I built Emacs —with-json this time. Performance is still better but it’s still stuttery. I guess it’s related to either the json parsing happening on the main thread and/or the LSP servers using company-capf which I think is a synchronous backend? It seems like coc.nvim, lsp bridge, kak-lsp, and other editor solution’s i’ve come across all opt to use sidecar processes that manage lsp. Perhaps Elisp isn’t the right tool for that backend processing.
      - deagle50 4y ago
        This can be spun off into another thread. I haven't tried it yet but the feedback has been excellent. https://reddit.com/r/emacs/comments/ymrkyn/async_nonblocking_jsonrpc_or_lsp_performance/ https://reddit.com/r/emacs/comments/ymrkyn/async_nonblocking...
        jpe90 4y ago
        Oh what a great idea! I hope this can get mainlined someday(perhaps behind a config option) since Eglot should benefit from that approach as well!