[mplanchard]

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).

[lanstin]

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.

[mplanchard]

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

[lanstin]

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