4 ms·

If your lsp-client code is doing anything where you need binding with a native library or the speed of emacs lisp is a factor, you are doing it wrong. All an ls

If your lsp-client code is doing anything where you need binding with a native library or the speed of emacs lisp is a factor, you are doing it wrong. All an lsp-client needs to do is make requests to the lsp-server, listen to the responses and update the UI. It literally doesn't matter how slow emacs-lisp is. The only way an lsp-client could be slow is by making a request to the server and then blocking on the response - which is wrong and the package writer's fault because they are not using the asynchronous api emacs provides for communicating with a process.

gcommer 4y ago
There's tons of little details and inefficiencies in elisp that crop up such that easy things like "listen to responses" are hard to get fast. Random example: before native json support, large lsp responses (which can be multiple megabytes from some servers!) would take over a second and hitch the UI just to parse the json response. And that was after a lot of work to get response parsing dominated by json instead of GC time.