You are not logged in.
(I also asked this on emacs stackexchange https://emacs.stackexchange.com/questio … n-emacs-30 edit: with (partial) solution)
Since I updated to emacs-wayland 30.1 every package update (currently on 30.1-3) from the arch repos gives me quite large memory leaks (well technically massive memory usage that constantly rises, not sure its 100% leaking) along with quite high cpu usage (yes my cpu is not very powerful, but still).
My assumption, and result of some testing with emacs -Q and running my config line by line it seems the use-package statements each resulting in significant memory and cpu usage and I think them all being executed at once is causing this? Additionally it only happens on the first couple opens/daemon starts (i.e. it happens with or without the daemon). After a bit it'll have finished and emacs will work normally again.
The way I'm currently dealing with this is letting the daemon run, but pkill-ing emacs each time it uses above 10G memory, at which point the systemd service restarts the daemon, freeing the memory again (immediately ramping up again, but still).
This feels like something that should be reported upstream, but I don't know where to start on this, any tips for further testing/ what to write?
Last edited by 0815 (2025-02-26 11:42:25)
Offline
What if you run normal emacs on xorg-wayland? Will it behave different?
Offline
Could this be related to native compilation? It's enabled by default in emacs 30 and was not enabled by default previously. To be clear, what one would expect if native compilation is the issue is that at each new version (or build) of emacs you would expect to see very high CPU usage (and somewhat higher memory usage) for a while as all of your elisp packages are loaded and compiled to binaries. However, once that compilation well and truly finishes you then wouldn't expect to see higher CPU and MEM usage again until the next version/build of emacs is installed (assuming that you're not otherwise flushing the eln cache or something in between startups).
That all sounds consistent with it only happening the first few starts and then working normally again after that, but you would expect it to stay normal until the next upgrade. There have been rapid point releases recently so that might be making it seem to be happening more often?
You can test this by disabling native compilation and seeing if that resolves your issue. That said, if it is a native comp issue, you should consider letting it run as emacs will run faster once its done. If the issue is that emacs is exhausting all available memory, consider adding a defer to some of your use-package blocks or otherwise lazy-loading them?
Last edited by mwillems (2025-02-26 18:12:25)
Offline
What if you run normal emacs on xorg-wayland? Will it behave different?
No, I just checked and that does not change anything.
Could this be related to native compilation?
Yes that is what I think is most likely (conversation on stackexchange). What I'm talking about is the fact that it is leaking memory, the largest I've seen before pkill-ing is over 10G, which should never happen. I could also make it work by `emacs -Q`-ing and running each section of my init file separately (which is approximately what would happen with lazy-loading I think?).
The whole emacs instance (whether daemon or not) freezes up and leaks the memory while also maxing out a single cpu core (last one is ofc not really bad, just normal)
What I'm currently trying to do is to whittle down my config to see what to write into a bug report as a minimal instructionset for others to attempt replicate, though I think it might just be sheer volume, so not sure if that's possible.
Last edited by 0815 (2025-02-26 18:38:51)
Offline