My IDE is too heavy so I moved to Emacs

Re:My IDE is too heavy so I moved to Emacs by ragnese on Tuesday December 13, 2022 @08:33AM (#33968570)

Yeah, Emacs's performance isn't really that great when going head-to-head as an IDE. Yes, it uses less memory and disk cache, but if we're talking about, e.g., working on a large Rust project with Emacs+lsp-mode/eglot+rust-analyzer, you're going to be in the ballpark of IntelliJ for memory usage, and the responsiveness will be nowhere near it. I will say, though, that the disk usage will be much less, and that has mattered for me on this 256GB disk MBP- between Xcode, Docker, and all these package managers for various languages, my disk space has become a precious commodity.

I still like Emacs. I prefer free software. I love Magit. But, the UI responsiveness is honestly frustrating when using LSP.

[ Parent | on HN ]

Re:My IDE is too heavy so I moved to Emacs by zozbot234 on Tuesday December 13, 2022 @07:17PM (#33978257)

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.

[ Parent | on HN ]

Re:My IDE is too heavy so I moved to Emacs by ragnese on Wednesday December 14, 2022 @10:27AM (#33984766)

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.

[ Parent | on HN ]

Re:My IDE is too heavy so I moved to Emacs by tadfisher on Wednesday December 14, 2022 @12:49AM (#33980409)

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.

[ Parent | on HN ]

Re:My IDE is too heavy so I moved to Emacs by jmount on Tuesday December 13, 2022 @09:39AM (#33969426)

For me Emacs pretty much grinds to a halt if I turn on showing line numbers.

[ Parent | on HN ]

Re:My IDE is too heavy so I moved to Emacs by TacticalCoder on Tuesday December 13, 2022 @11:16AM (#33970856)

Try to determine which one you're using by running "M-x linum-mode" and then "M-x display-line-numbers-mode". Note that you can use both at the same time (which would make zero sense: it's only to troubleshoot which one is problematic for you).

Do not use linum-mode anymore.

I can display buffers with hundreds of thousands of lines while showing the line numbers (Emacs 29 / native compilation / display-line-numbers-mode / CPU is an AMD 3700X with 32 GB of RAM) and Emacs is ultra responsive.

[ Parent | on HN ]

Re:My IDE is too heavy so I moved to Emacs by mort96 on Tuesday December 13, 2022 @12:13PM (#33971912)

This is the kind of thing which infuriates me the most about emacs. There are thousands of similar but not equivalent ways of doing the same thing, both StackOverflow and the emacs wiki contains some (but not all, and not the same, and usually not the right, and usually contradictory) ways of doing things. And it's impossible to figure out which way is the right one without asking around in IRC channels.

Why oh why couldn't they improve linenum-mode instead of introducing a new mode.

[ Parent | on HN ]

Re:My IDE is too heavy so I moved to Emacs by ParetoOptimal on Tuesday December 13, 2022 @01:27PM (#33973440)

> There are thousands of similar but not equivalent ways of doing the same thing, both StackOverflow and the emacs wiki contains some

What about the manual?

https://www.gnu.org/software/emacs/manual/html_node/emacs/Di...

The issues you described are mostly totally solved by looking in the manual first rather than externally.

> Why oh why couldn't they improve linenum-mode instead of introducing a new mode.

The double-edged sword of being very backwards compatible.

[ Parent | on HN ]

Re:My IDE is too heavy so I moved to Emacs by User23 on Tuesday December 13, 2022 @09:49AM (#33969561)

You’re probably using the old notoriously slow linum-mode. The newer line-number-mode is much snappier.

[ Parent | on HN ]