Live data from Hacker News

Advanced techniques for reducing Emacs startup time

blog.d46.us

71–80 of 83 posts

Re: Advanced techniques for reducing Emacs startup time

#71

Earlier quoted context omitted.

I hope this doesn't come along as aggressive but: Do you really have a "different use case", or are you just averse to the idea of running it in the background as a daemon? Do you really need to save the 70 MB (without addons) to 200 MB (with addons) that it takes sitting there? Unlike bloated Electron apps, Emacs doesn't actually use CPU while you're not using it - it just sits there, takes up a little memory (and e…

I don't know I'm not an "emacs guy" really, I didn't know about this feature. It will probably work for me and I'll consider setting it up the next time I twiddle with my emacs config, something I do for an hour or two about once a year. But whether or not it solves my problem yes I think the use case is different? The person I responded to uses it so consistently they leave it running at all times. I can go days or…

Ah, well, if you're going days/weeks between using it, then I understand why it wouldn't be useful for you to figure out how to configurate it more, and why leaving it running in the background would be mostly a waste. That makes sense.

Although, now, I'm sure that many of us are curious - why would you only use Emacs this infrequently, but bother to use it at all?

Re: Advanced techniques for reducing Emacs startup time

#72

Eight Megabytes And Constantly Swapping :)

Emacs has a default buffer gc trigger at 800kb. I increased this to 1gb which mostly improves UX (no gc while scrolling) but I’m fairly sure other apps memory leak all their way to 1gb.

gc-cons-threshold and gc-cons-percentage, for those curious.

https://elmord.org/blog/?entry=20190913-emacs-gc

Re: Advanced techniques for reducing Emacs startup time

#73
One of the problems I never knew I had. Made me curious, how long does it actually take to start. Not entirely trivial to determine, but for the initialization time, Emacs has a function which reports it (of course):

  (emacs-init-time)
  "4.7 seconds"
Holy cow, that's a lot. But perhaps given that this is a first gen. Banana Pi (1GHz dual-core ARM32) not actually all that much. And given

  (emacs-uptime)
  "99 days, 3 hours, 14 minutes, 25 seconds"
not significant either.

Re: Advanced techniques for reducing Emacs startup time

#74
Author here. Things that have changed since I published this.

- Doom emacs does most (all) of these with a bunch of cleverer techniques than mine. I’d recommend doom over rolling your own emacs.

- I use IntelliJ just about exclusively.

- I now do the minimal amount of customization I can get away with.

Re: Advanced techniques for reducing Emacs startup time

#75

Earlier quoted context omitted.

I don't know I'm not an "emacs guy" really, I didn't know about this feature. It will probably work for me and I'll consider setting it up the next time I twiddle with my emacs config, something I do for an hour or two about once a year. But whether or not it solves my problem yes I think the use case is different? The person I responded to uses it so consistently they leave it running at all times. I can go days or…

Ah, well, if you're going days/weeks between using it, then I understand why it wouldn't be useful for you to figure out how to configurate it more, and why leaving it running in the background would be mostly a waste. That makes sense. Although, now, I'm sure that many of us are curious - why would you only use Emacs this infrequently, but bother to use it at all?

I used to use it a lot and do prefer it in the abstract. Just, my daily work has shifted to where I spend a lot more time exploring unfamiliar codebases, making small changes and refactors, and pairing in them. I work in a lot of different languages. Maintaining an emacs config that is truly very good at everything started to feel like a part time job on its own.

Plus I work remote and for better or worse vs code has become conventional for remote pairing. So I have a minimal emacs config for when I don't need any particular language integration, and the rest of the time vs code is good enough for the daily work I actually do, which is rarely writing out features from scratch anymore.

Re: Advanced techniques for reducing Emacs startup time

#76

From the article, in rebuttal to the "use daemon mode" argument: > Fast things feel nicer. Daemon mode is fast. Mine takes less than a second to open a new frame with a fully-loaded Spacemacs setup, and while my startup time is 20-30 seconds, it runs in the background upon login, and I don't care about that gap. > When customizing Emacs, you sometimes get into weird states that can be hard to recover from without res…

20-30 seconds? I thought VSCode was slow and that only takes about 10 (with lots of heavy extensions).

Re: Advanced techniques for reducing Emacs startup time

#78
post #3

Easiest thing is just not to quit! I stopped autoloading things, as i found it less bothersome to wait 30 seconds for Emacs to load than to get surprised by an autoload delay while working.

Sadly my emacs freezes about once every 2 weeks. Hand rolled config that restores everything within 30 seconds. But still.

Re: Advanced techniques for reducing Emacs startup time

#79
post #51

Earlier quoted context omitted.

It was subtle in my message, but my other reason for disabling was to avoid random collection pauses when using emacs. A sibling poster recommended GCing on deactivate, which is an interesting idea! But again, I truly haven't been able to notice any ill effects of not GCing. I tend to probably leave emacs open for maybe a few hours at a time, so I guess in that sense I'm manually GCing. :-)

Not running the GC at all is certainly interesting though :) Have you tried running 'M-x memory-report' before quitting to see how much memory you ended up using?

My emacs ain't new enough to have memory-report. I tried just running memory-report.el from HEAD, but it errored out (after hanging emacs for like 3 mins!).

Anyway, here's the poor man's version:

cons-cells-consed is 38315202

There's probably some roughly accurate map from that to number of bytes of memory allocated, I will take a totally random guess it's 10, which would give 383MB of memory used.

I'm at half a day of usage, so figure 800MB by end of day. 16GB machine, so you can see why my "garbage collect once a day before bed" strategy is working out ;-).

(Plus also I wonder how much of the uncollected garbage just gets paged out by the OS and never touched again.)

Re: Advanced techniques for reducing Emacs startup time

#80

I gave up on Emacs and went back to Vim because of the slowness and the bugs I was encountering while using the Emacs GUI (granted a lot of them were from lsp-mode and other heavy packages). While digging for answers I was told not to use certain platforms, don't use the GUI, use the GUI, don't turn Emacs off etc. which felt like Stockholm syndrome to me. There's a lot of cargo culted config fragments like the ones y…

My init files are nearly 10k lines and I have >300 packages. I've never "declared .emacs bankruptcy." Emacs starts in 0.4-0.6 seconds (without the daemon) for me. One reason I initially switched to Emacs was because Vim was comparably slow as hell for what I was doing. That's no longer the case. Neovim and Vim are definitely faster than Emacs, but I almost never run into cases where it matters. Even on my crappy work laptop, the only time I ran into issues with Emacs is when dealing with log files that were gigabytes (in cases like that evil's :g and :s are just unusably slow).

> There's a lot of cargo culted config fragments like the ones you'll find in the article.

Besides changing the gc-cons-threshold (which is indeed a questionable fragment to blindly copy/paste), there were no other specific config fragments, only examples. People blindly paste config fragments for everything (e.g. set nocompatible in Vim).

> Why does every user have to constantly reinvent the same config to work around all of the issues in Emacs?

What is there to reinvent? It should take almost no extra configuration to properly defer package loading. Package loading is also not automatic. If you are explicitly loading every package you've installed during init, that's your fault. You shouldn't blindly copy things into your config. If you really don't want to handle configuration yourself, starter kits exist for a reason.

> In the article the author talks about how he's gone bankrupt three times with his config, maybe that's a sign that the problem isn't the author. If Emacs is that fragile, then its extensibility is really a moot point.

It is mostly a user problem. Emacs lets you do anything. It gives you enough rope to hang yourself with. I could write an unreadable and broken mess of a program in any programming language, but that doesn't say anything about whether a language is fundamentally flawed.

It's a double-edged sword. There's no such thing as bug-free software. And the more functionality, the more room for misconfiguration and bugs. Vim/neovim come nowhere close in terms of functionality. The correct word isn't "fragile." A better word would be "malleable." It's the editable editor. Emacs' malleability is at least part of the reason why it's able to stay relevant despite the fact that it has very few developers compared to Vim and other editors. Because Emacs is this way, it's potentially easier to do something dumb or install a bunch of useless, slow packages, but because Emacs is this way we also have Magit, org-mode, and a bunch of other killer packages that Vim has much worse versions of (or no equivalent of at all).

This means that if you only need a simple setup, Emacs is not that appealing, but my experience has been that I have no idea what I want until I know what is actually possible (e.g. I didn't grok magit until I read the entire manual and saw how greatly it would simplify my workflow).

Post reply on HN