Significant performance issues, am I doing anything really stupid?

I know emacs isn't supposed to be super snappy, but it is ridiculously slow, to the point where I'm convinced that I've done something terribly wrong. It's just a little slow on startup and gets progressively worse and is borderline unusable after about half an hour. All my packages are natively compiled. (From nix) I'm using lsp-mode with haskell-language-server. It's also bad with rust-analyzer, but not as bad. It affects all versions I've tried, including latest master and the lsp-mode experimental fork (which improved stuff but broke direnv, so...) I've tried the default gc limit, a high limit, a manual idle timeout and gcmh. It's much snappier in the terminal, but still not as good as I want it (and the whole gui thing was the reason I tried to switch away from neovim). So now I'm convinced that there's no way you all live with this and that I must've done something really stupid. Here's (the relevant parts of) my config: https://github.com/SKyletoft/dotfiles/blob/master/emacs https://github.com/SKyletoft/dotfiles/blob/master/emacs.d/configs/language-specifics.el

This might give you and us some idea of what's going on: When stuff gets slow, call `M-x profiler-start` -- use Emacs for a little while, or, better yet, invoke the specific "slow" actions -- and then call `M-x profiler-report`. And then you'll be hopefully able to post the profiler output here, or even make your own conclusions right away,

I have the same issue with lsp-mode, tree sitter, rust-analyzer and rustic... works really well and is snappy for a few hours, then it starts getting slower and slower. I can leave it like this for maybe half a day's work then i need to restart emacs. I noticed that the slow downs are worst toward the end of the file being edited. This prompted me to bite the bullet and redo my whole configuration, removing stuff that I had been lugging around for a decade and a half. But nope, still the same issue. I considered switching to neovim or even (gasps in the audience) VSCode... But i just can't. Hoping that at some point someone more knowledgeable will find what's wrong with the setup.

Can only suggest to disable some packages for a while and check if this resolves the issue - lsp-mode should be OK (I never ran into this at least), although recently I swapped it out for eglot which is a little faster. Also, maybe this helps: (add-function :after after-focus-change-function (lambda () (unless (frame-focus-state) (garbage-collect))))

Thanks, I'll give a try to your suggestion (tho I think I should have the GC situation nailed down). I'll also try to take a profiler report as per hvis advice.

It should not be slow at all. I am running emacs-29 on M1 macs, and it *is* snappy. It starts up in about 1s, and it's stupid fast. I did take care to compile an arm64 native emacs. I also run emacs on linux systems with Xeon and i7 processors, and it's not slow. I don't enable native compilation. Use the profiler to get a report as hvis suggested.

There is a newish feature, undo-tree-something or other. My Emacs was getting slower and slower and slower, then I realized it was manipulating undo trees that are 3 GB in size (and hidden from view with dots in their names :). Find a way to turn off this feature, delete the files, and things might be better!

You might also check `M-x memory-report` to see if there's any huge values hanging around. Also, do both cpu and mem with `M-x profiler-start`.

Run emacs with `emacs -Q`. If you no longer see the slowdown, you know it's an issue in your configuration. From there, comment out half your configuration, restart and see if the performance issue comes back, if yes, the issue is in that half, if not, it's in the other half. Continue like that, basically binary searching your config until you've identified the problematic section. Also, there's a "nix-mode" package with actual hooks, so you don't have to do that weird find-file-hook thing, just fyi... Edit: And just as a benchmark, I am running emacs 28, natively compiled. Mine starts in less than a second with roughly 50 extra packages.

Or try eglot instead of lsp-mode

Try going to the Development menu and unchecking "Semantic Database" and "Reparse when idle" options. It's CEDET stuff that IIRC was turned on by default sometime recently.

See https://github.com/redguardtoo/emacs.d#set-up-lsp-mode

The nix.mode hook wasn't being respected, so that's why I did that. I tried the hook first

>And just as a benchmark, I am running emacs 28, natively compiled. Mine starts in less than a second with roughly 50 extra packages. Doom 28.2, nativecomp but not ahead of time, a bit over 300 packages, starts in ~0.7-1.5s.

> It's CEDET stuff that IIRC was turned on by default sometime recently. I'm pretty sure that's not the case: CEDET should still be off by default. Moreso now that it's rarely seeing any new development.

For me, Emacs starts up with those items checked in the menu, and after about 20 minutes I gave up trying to figure out which variables these items correspond to :) but perhaps you are right, I do have the sr-speedbar loaded, perhaps that triggers CEDET...

> I do have the sr-speedbar loaded, perhaps that triggers CEDET `speedbar` does have some Semantic support. Whether it also enables the mode, I have no idea. Doesn't look like from a cursory glance, though.

And if you want a graphical undo without the large underlying data structure, give [vundo](https://github.com/casouri/vundo) a try. It just re-uses the same undo data structure emacs already keeps.

lsp-mode is much faster especially with LSP Emacs fork.

That sounds suspicious, hooks are pretty fundamental. I would file an issue with them if you get the chance, and maybe try disabling that package in particular. I assume you mean `nix-mode-hook`.

[Profile](https://i.imgur.com/Z88fM97.png) It wasn't slowing down anywhere close to as much today as it's been doing over the past few days, though it's still much slower than I'd like. At least there were no outright freezes, though I guess that's bad from a profiling point of view. It looks like it's mostly evil and redrawing that's the problem. And surprisingly telephone line.

The entries are expandable with `TAB`, so you can drill down those which have significant percentages. And mode-line packages can indeed pose a problem if not optimized properly: the mode-line is redrawn on every redisplay.

Yeah, that's how I found that the rendering was mostly the modeline and evil. But serious issues never showed up when I was profiling, so I'll just have to try again when they do. But it seems weird that the modeline doesn't cache what it can if drawing is so expensive

The mode-line itself doesn't cache because it doesn't know whether the contents have changed. Or rather it does cache what it knows, but the description language allows arbitrary eval forms. So it's up to the package.

The thing isn't about fastness at first, but of long-time fastness. If something gets slower and slower over time, one can expect a memory leak. Or some linked list that is going longer and longer, maybe even with dead entries, and therefore some quadratic behavior when searching in it. An Emacs patched to have better thread support, so that lsp-mode support might not fix it. Changing the algorithm to use LSP, e.g. from lsp-mode to eglot or to lsp-bridge, however migth. Maybe the some linked-list travelling of an ever-growing link list won't happen here? If yes, you'll find it out with profiling, valgrind, or just using it for some hours.

lsp-mode maintainer here - there was a leak recently fixed in lsp-mode causing a slowdown after some time. Also, in general, if you observe misbehavior like that it will be great if you can report it back.

How recent?

1 week ago.