Hacker News Reader

Comment by okasaki | Hacker News Reader

Emacs is pretty snappy these days, what kind of performance problems are you seeing with it?

Especially with the native compilation in newer versions. Wow! That was a night and day difference. Before, I tolerated it. Now, I very rarely wait for anything.

Yeah, it's positively snappy.

I love Emacs and it has been my number one tool for a long time. It is definitely more efficient with native compilation but there are still some issues. For example, get a large code base and obtain all occurrences of an expression in the whole code base. Every IDE is going to stutter on this but Emacs will pretty much lock up until this completes.

Have you tried any plugins using ripgrep? Searching for expressions in Neovim is pretty much instant using fzf-lua or any-jump, the latter is based on the emacs package https://github.com/jacktasia/dumb-jump

I use emacs every day, with a minimal config, and would never describe it as snappy. The entire thing is single threaded so the UI locks up at the slightest provocation, like for example when firing network requests whilst packages are updating.

Emacs can run external processes asynchronously. It is true that Emacs locks up while updating packages but it is actually not while downloading or unpacking them! It locks up while byte-compiling them. :)

Maybe it can but it sometimes doesn't.

I remember I looked into a lockup I was experiencing (this was a few years a ago so I forget the mode). Turns out emacs was writing to disk every so often and this was noticeably causing stutters in the main thread.

You are correct, my emacs locks up constantly. Mostly due to linting and syntax highlighting, but also with the emacs terminal.

It really depends on the package, but too many fundamental packages are still operating in the main event loop.

Okay, well either way, the UX is atrocious.

What is it that bothers you about the UX?

> would never describe it as snappy. The entire thing is single threaded so the UI locks up at the slightest provocation

This part seems to be about the User eXperience. (which I agree with, but elisp can start child processes and wait for the results asynchronously, so this is the fault of whoever wrote the code https://www.gnu.org/software/emacs/manual/html_node/elisp/Ou... )

I've been using Emacs for over 25 years, and I cannot agree at all with the sentiment that the UI locks up frequently. I mean, it depends on exactly what you do with the program, but for me, the UI is always responsive.

Emacs is snappy in the terminal with the tui version while the gui versions are still really slow for me. Hopefully someone will make a fast frontend with GPUI or something because the lisp engine is certainly fast enough these days

I use spacemacs and have problems with the editor locking up when some extension does some a lot of work.

There's also a strange bug (at least I think it's a bug and not a feature that I don't know how to use) where the cursor will still exists and clicking will move it around, but the window doesn't respond to keyboard inputs.

Yeah it's much better than it used to be for sure. I recently dumped doom-emacs and went through the process of setting things up from scratch, and mostly performance is pretty good.

I think that it still struggles a bit when I have many (>100) buffers open, largely I think because of anything that has to do window management winding up iterating over every buffer, and it turns out a lot of things (both internal and third-party packages) wind up doing this on various hooks that make the overall experience feel sluggish.

I also still see occasional performance issues with eglot/LSP on very large projects, especially around input feeling laggy while the language server is churning on something.

In general, it's frustrating when stuff that /should/ be in the background and not have any effect on actual editing latency winds up causing slowness or hangs. A good example is any time font-locking gets complicated, e.g. on very large files (which again has improved in recent versions).

Yeah, it's better to use one emacs per project, and have less buffers open at a time. Not just the snappiness but a lot of the (out of the box, no special modes) keyboard buffer navigation stuff doesn't scale to hundreds of buffers. Maybe if I had better file naming conventions, but I tend to have a main.go in each cmd and sometimes even in pkg. I also rarely learn new modes/packages, as they aren't in on the VMs and so on that I also like to use emacs on.

My day job is in a fairly large codebase so I often wind up with tons of buffers open just from jumping around following definitions. I’ve taken to just opening ibuffer every once in a while and nuking everything

Buffer cleaning is a time honored way to pause for deep thinking :)

Huh?

I (used to) use it almost exclusively with eglot lsp to python language server (Jedi I think). I run emacsfoacosx 29.2 and now .3. And I’ve used it since 1996 on emacs 18 on a b/w sun workstation.

But most recently on the last 2020 intel MacBook Pro.

The cursor moving speed through a source file is atrocious. Maybe 3 - 4 lines per second vertical and similarly horizontal.

The shell just freezes on long lines and forget about font lock for multi MB json.

All of these tasks would be hard a decade ago but now aren’t even table stakes.

It just /feels/ sluggish.

I reluctantly just gave up. It was fast way back then but I think workloads have changed. I tried zed for a bit but have now reluctantly gone to pycharm CE. If you accept the different windowing metaphor and add bindings for C-a and C-e and friends (some are standard) it’s not bad. And never sluggish (same hardware).

I love emacs but for my outlandish workload of python programming and wrangling multi MB text output it just doesn’t perform.

I speculate it isn’t straight line speed but threading that is hurting perceived latency.

Did you try vterm (libvterm based)? It is uncomparably faster than M-x shell or M-x term, in case you were using them.

Reply on news.ycombinator.com