4 ms·

I'm 100% not trolling with this question, I really like Emacs, buuut: Does it fix having to restart Emacs after at most 8-16 hours of use? Could this experien

I'm 100% not trolling with this question, I really like Emacs, buuut: Does it fix having to restart Emacs after at most 8-16 hours of use? Could this experience be a plugin I use, or my own idiocy? Originally, I assumed "YES! Of course! I am idiot... This is my fault!" Then came the observation when pairing with people (across a variety of languages) who use Emacs, who all say on a regular basis, without so much as a thought to it: "one sec, I just need to restart Emacs." Followed by 30 seconds of restarting Emacs and 30 more seconds setting up the buffers. I'd definitely use Emacs but the inevitable, and uncontrollable, lockups kill it for me.

ashton314 5y ago
I'd bet it's just your setup. I had one Emacs session run for almost a month straight—and that was with LSP mode running on a fairly large Elixir project. I only restarted it because I needed to restart the machine I was running it on. It was using barely over 300 MB of RAM. (Lots and lots of open buffers and whatnot.) That's not an unusual occurrence for me—and I'm not even running the native-comp branch yet! FWIW, my Emacs init time (run `emacs-init-time`) is between 2–7 seconds, and I'm not doing anything particularly special to get that working. I'd start out with a fresh .emacs config file and then add the packages you want with the excellent `use-package` macro, setting `:defer t` as much as possible. (Often this will be implicit if you have `:mode`, `:hook`, or `:bind` configured, if I'm not mistaken.) It would be better if Emacs were less sensitive to how your config is setup, but alas, we live in a fallen world. You can also ask around on r/emacs and get some better tips than mine.
- kfajdsl 5y ago
  I basic used `:defer t` for a while (Doom Emacs lazy loaded under the hood), but when I switched to my own config I decided to just run it in daemon mode and use `:demand t` on everything. I didn't like pauses sometimes when opening a new file while it loaded a package. Actually, I just checked my init time with that command, and it's ~2.5 seconds. I wouldn't call my config heavyweight, but it does have evil, lsp, vterm, ivy, magic, etc. I am using the native-comp branch though.
wyuenho 5y ago
Sounds like you have a memory leak somewhere or some code in your emacs setup is using a lot of memory and is causing lots of gc. Turning on garbage-collection-messages and profiling memory usage will be a start to debug this.
didibus 5y ago
I'm not affected by this, so you might have something weird specific to your setup.
- tejuis 5y ago
  I've been running Emacs for almost 30 years. Stability has never been a problem and the last 5-10 years it has been rock solid for me. I can run Emacs for months without restart. Hence instability must be an issue with some packages.
neolog 5y ago
I used to get that all the time until I uninstalled some melpa package.
josteink 5y ago
> Could this experience be a plugin I use, or my own idiocy? Considering how lots of people prefer to start Emacs once, preferably as a server (maybe even as a systemd user-unit!), and keep it running forever, not even closing buffers, until eventually the machine must be rebooted for whatever reason... I would have to say yes.
nick_kline 5y ago
I never need to restart emacs. It's generally only when I reboot that I have to start emacs again.
triska 5y ago
You can try this code snippet to detect large variables: https://lists.gnu.org/archive/html/emacs-devel/2008-12/msg00770.html https://lists.gnu.org/archive/html/emacs-devel/2008-12/msg00... It is a major attraction of Emacs that its inspection facilities can be easily used to automatically analyze such issues. My expectation of Emacs is that I never have to restart it. If it crashes or fails to reliably reclaim memory, please consider filing an issue with M-x report-emacs-bug RET.
jamienicol 5y ago
I would say it likely is your, and their, setups. But not idiocy. The way Emacs configuration works makes it very easy to break (but also very powerful)
theshrike79 5y ago
I had an org-mode emacs session running 24/7 on a server for months at a time without any issues. It's something with your setup.
marco_craveiro 5y ago
I run Emacs on both Linux and Windows and I find that with more or less the same packages, the Windows Emacs tends to "slow down" after a while. I've used the profiler to track down a couple of things that were causing slowdowns (ibuffer auto refresh, etc), but still haven't quite go to the point where Windows runs as fast as Emacs. On both cases I have fairly long running Emacs sessions - around a month on Linux, when I pickup distro updates, and a week on Windows as we do mandatory reboots weekly. I recommend you try profiling to see if something shows up [1]. [1] https://200ok.ch/posts/2020-10-01_introduction_to_profiling_in_emacs.html https://200ok.ch/posts/2020-10-01_introduction_to_profiling_...
- TeMPOraL 5y ago
  I spent some time poking Emacs on Windows with a profiler too, also to no avail (few things I identified as suspect turned out to didn't matter). I eventually resigned to running Emacs under WSL1 and rendering it on VcXsrv on Windows side. It's very fast this way, though some filesystem-heavy operations are still slightly slower than they would be on Linux (that's a limitation of WSL and NTFS). About the only issue I have with this setup is that I can't get color emojis to work using Microsoft's Segoe UI Emoji :). That, and if I want to call out to some Windows executable, I have to ensure I use :connection-type 'pipe instead of (the default) TTY in make-process, because otherwise I get a disconnected process that can't communicate with Emacs. But the latter is a very rare case (I only need it to drive the build system I use at work from Emacs, because it lives Windows-side).
TeMPOraL 5y ago
Definitely your setup. Long uptimes for Emacs with no performance degradation are common. Mine are typically month+. Currently, M-x uptime on my desktop (Linux) shows 33 days; on my work machine (Windows, with Emacs in WSL) it's 5 days - but that's only because I wrote a lot of tricky Elisp code to optimize my work some, and I rebooted Emacs to check it will actually work when reloaded afresh. Normally, Emacs runs uninterrupted on that machine, until Windows forces me to reboot for updates. Startup time with nativecomp? Typically around 5 seconds on Linux, 15 seconds on WSL. If I happened to update a lot of packages before restarting (as I sometimes do, I like to clean out runtime state when I do bulk updates), then on WSL the startup goes up to about 1-2 minutes - that is, Emacs is usable in about 30 seconds, but async native compilation keeps pinning most CPU cores, so I just let it work in peace for that extra minute.
Siira 5y ago
It's your own setup's fault. I use emacs daily, and I almost never have to restart it.
kfajdsl 5y ago
I've never experienced this. I autostart emacs in daemon mode, and right now my desktop's uptime is... 3 days. And that's only because I updated my kernel, normally I'll go for a lot longer than that.
samus 5y ago
30 seconds for startup is really weird. Mine starts in a few seconds, and is far from fully customized. Initializing the language servers of open buffers takes by far the most time. Emacs has many solutions to restore buffers. I use `desktop`, which is built-in. Use whichever you like, I really can't tell you the pros/cons. Have you ever tried setting the garbage collection treshold to a large value? There's definitely no use for it during startup. It might make sense though to trigger it in a hook after startup.

ashton314 5y ago

I'd bet it's just your setup. I had one Emacs session run for almost a month straight—and that was with LSP mode running on a fairly large Elixir project. I only restarted it because I needed to restart the machine I was running it on. It was using barely over 300 MB of RAM. (Lots and lots of open buffers and whatnot.) That's not an unusual occurrence for me—and I'm not even running the native-comp branch yet! FWIW, my Emacs init time (run `emacs-init-time`) is between 2–7 seconds, and I'm not doing anything particularly special to get that working. I'd start out with a fresh .emacs config file and then add the packages you want with the excellent `use-package` macro, setting `:defer t` as much as possible. (Often this will be implicit if you have `:mode`, `:hook`, or `:bind` configured, if I'm not mistaken.) It would be better if Emacs were less sensitive to how your config is setup, but alas, we live in a fallen world. You can also ask around on r/emacs and get some better tips than mine.

kfajdsl 5y ago
I basic used `:defer t` for a while (Doom Emacs lazy loaded under the hood), but when I switched to my own config I decided to just run it in daemon mode and use `:demand t` on everything. I didn't like pauses sometimes when opening a new file while it loaded a package. Actually, I just checked my init time with that command, and it's ~2.5 seconds. I wouldn't call my config heavyweight, but it does have evil, lsp, vterm, ivy, magic, etc. I am using the native-comp branch though.

wyuenho 5y ago

Sounds like you have a memory leak somewhere or some code in your emacs setup is using a lot of memory and is causing lots of gc. Turning on garbage-collection-messages and profiling memory usage will be a start to debug this.

didibus 5y ago

I'm not affected by this, so you might have something weird specific to your setup.

tejuis 5y ago
I've been running Emacs for almost 30 years. Stability has never been a problem and the last 5-10 years it has been rock solid for me. I can run Emacs for months without restart. Hence instability must be an issue with some packages.

neolog 5y ago

I used to get that all the time until I uninstalled some melpa package.

josteink 5y ago

> Could this experience be a plugin I use, or my own idiocy? Considering how lots of people prefer to start Emacs once, preferably as a server (maybe even as a systemd user-unit!), and keep it running forever, not even closing buffers, until eventually the machine must be rebooted for whatever reason... I would have to say yes.

nick_kline 5y ago

I never need to restart emacs. It's generally only when I reboot that I have to start emacs again.

triska 5y ago

You can try this code snippet to detect large variables: https://lists.gnu.org/archive/html/emacs-devel/2008-12/msg00770.html https://lists.gnu.org/archive/html/emacs-devel/2008-12/msg00... It is a major attraction of Emacs that its inspection facilities can be easily used to automatically analyze such issues. My expectation of Emacs is that I never have to restart it. If it crashes or fails to reliably reclaim memory, please consider filing an issue with M-x report-emacs-bug RET.

jamienicol 5y ago

I would say it likely is your, and their, setups. But not idiocy. The way Emacs configuration works makes it very easy to break (but also very powerful)

theshrike79 5y ago

I had an org-mode emacs session running 24/7 on a server for months at a time without any issues. It's something with your setup.

marco_craveiro 5y ago

I run Emacs on both Linux and Windows and I find that with more or less the same packages, the Windows Emacs tends to "slow down" after a while. I've used the profiler to track down a couple of things that were causing slowdowns (ibuffer auto refresh, etc), but still haven't quite go to the point where Windows runs as fast as Emacs. On both cases I have fairly long running Emacs sessions - around a month on Linux, when I pickup distro updates, and a week on Windows as we do mandatory reboots weekly. I recommend you try profiling to see if something shows up [1]. [1] https://200ok.ch/posts/2020-10-01_introduction_to_profiling_in_emacs.html https://200ok.ch/posts/2020-10-01_introduction_to_profiling_...

TeMPOraL 5y ago
I spent some time poking Emacs on Windows with a profiler too, also to no avail (few things I identified as suspect turned out to didn't matter). I eventually resigned to running Emacs under WSL1 and rendering it on VcXsrv on Windows side. It's very fast this way, though some filesystem-heavy operations are still slightly slower than they would be on Linux (that's a limitation of WSL and NTFS). About the only issue I have with this setup is that I can't get color emojis to work using Microsoft's Segoe UI Emoji :). That, and if I want to call out to some Windows executable, I have to ensure I use :connection-type 'pipe instead of (the default) TTY in make-process, because otherwise I get a disconnected process that can't communicate with Emacs. But the latter is a very rare case (I only need it to drive the build system I use at work from Emacs, because it lives Windows-side).

TeMPOraL 5y ago

Definitely your setup. Long uptimes for Emacs with no performance degradation are common. Mine are typically month+. Currently, M-x uptime on my desktop (Linux) shows 33 days; on my work machine (Windows, with Emacs in WSL) it's 5 days - but that's only because I wrote a lot of tricky Elisp code to optimize my work some, and I rebooted Emacs to check it will actually work when reloaded afresh. Normally, Emacs runs uninterrupted on that machine, until Windows forces me to reboot for updates. Startup time with nativecomp? Typically around 5 seconds on Linux, 15 seconds on WSL. If I happened to update a lot of packages before restarting (as I sometimes do, I like to clean out runtime state when I do bulk updates), then on WSL the startup goes up to about 1-2 minutes - that is, Emacs is usable in about 30 seconds, but async native compilation keeps pinning most CPU cores, so I just let it work in peace for that extra minute.

Siira 5y ago

It's your own setup's fault. I use emacs daily, and I almost never have to restart it.

kfajdsl 5y ago

I've never experienced this. I autostart emacs in daemon mode, and right now my desktop's uptime is... 3 days. And that's only because I updated my kernel, normally I'll go for a lot longer than that.

samus 5y ago

30 seconds for startup is really weird. Mine starts in a few seconds, and is far from fully customized. Initializing the language servers of open buffers takes by far the most time. Emacs has many solutions to restore buffers. I use `desktop`, which is built-in. Use whichever you like, I really can't tell you the pros/cons. Have you ever tried setting the garbage collection treshold to a large value? There's definitely no use for it during startup. It might make sense though to trigger it in a hook after startup.