Hacker News new | ask | show | jobs
by zozbot234 1284 days ago
Wouldn't most of the slowness and memory use be due to rust-analyzer itself, which is notoriously slow and heavy for large projects? That has little to do with your IDE choice. Emacs devs are also working on tree-sitter parsing support, which might help reduce reliance on LSP more generally.
2 comments
tadfisher 1284 days ago
Emacs was built as a TUI, and it is built like a giant REPL; read input, evaluate command, print the output, and loop back. IDEs based on "modern" GUI frameworks (IntelliJ uses Swing, not exactly "modern") are inherently multi-threaded; you have the UI (or "main") thread that accepts events and updates the display, and ideally never blocks, while evaluation is performed on worker threads that can be canceled or scheduled as needed.

In practice, you can get far with Emacs' process supervision to avoid blocking the command loop, but some things that are trivial to offload to a worker thread are next-to-impossible to avoid blocking in Emacs. One of those things is parsing megabytes of JSON from an LSP server into Lisp data structures, which is baked into the Emacs core and will block redisplay.

link
ragnese 1284 days ago
Yes and no. I'm using rust-analyzer as an example, but I also use other language servers and observe similar UI lags/stutters.

When it comes to memory, my point is precisely that we should count the language server in the total and not just the Emacs process. So, when some other IDE is using multiple GB of memory on my Rust project, we have to compare that to my Emacs + rust-analyzer memory usage because both of those processes are providing the features that other-IDE is providing.

However, Emacs is also still kind of laggy when using LSP, even though the actual LSP server lives in another process and communicates mostly asynchronously. My understanding is that there are still bottlenecks in Emacs that make this not truly async. But, even if my LSP server of choice is extremely slow, why should that affect my cursor movement or typing speed in my Emacs buffer? I can see why it would be technically difficult to make it NOT introduce some lag, but it shouldn't in principle.

I haven't used Visual Studio Code, but my understanding is that it is plenty responsive to typing and cursor movement, even while using rust-analyzer.

link