Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Advanced techniques for reducing Emacs startup time

blog.d46.us

Post reply on HN
Print view View original

61–70 of 83 posts

Re: Advanced techniques for reducing Emacs startup time

#61

Post by throw10920 »

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 restarting. For example, if you add a slow lambda function to your post-command-hook, it’s tough to remove it.

> Restarting Emacs helps verify that customization will persist between sessions.

These only matter if your primary use-case for Emacs is...customizing Emacs. Which is a thing that some people do, I guess, but I'm more interested in using Emacs as a tool. Sure, I'm going to spend dozens of hours tweaking it, but I'll spend thousands of hours using it - and rewriting my init.el (especially from its current Spacemacs state) is also going to take dozens of hours, which will definitely wipe out any gains that I would have gotten from having a slightly faster iteration time during the elisp development loop.

That said, I still think that the information presented in the article is useful! It's always good to know why software is slow and how to make it faster, and some people just don't want to use daemon mode.

Re: Advanced techniques for reducing Emacs startup time

#62

Post by giraffe_lady »

throw10920 wrote: post #60
giraffe_lady wrote: post #31

Earlier quoted context omitted.

Just different use cases then. Emacs isn't my main coding tool these days but I still use it for single-file editing, and I close it when I'm done with that file. The start up time does matter to me somewhat. Though I have a pretty simple config for the same reason and it's not bad enough for me to spend time on. I do keep an eye on it though.

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 weeks between single uses, depending on the projects I'm working on. That's a very different use to me.

Re: Advanced techniques for reducing Emacs startup time

#63

Post by ParetoOptimal »

dilap wrote: post #33
ilovecaching wrote: post #19

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…

Yeah, as soon as you start customizing emacs (which is the whole point of emacs), you run into bugs. Everything is always slightly broken all the time; I don't think it's actually humanly possible to fix this -- too many parts. Fix one thing, another thing breaks. I'm addicted to the flexibility, but I dream of something that offers the same level of flexibility in a more robust ecosystem (e.g. statically typed, stat…

> Yeah, as soon as you start customizing emacs (which is the whole point of emacs), you run into bugs. Everything is always slightly broken all the time; I don't think it's actually humanly possible to fix this -- too many parts. Fix one thing, another thing breaks.

There's no difference between an advanced emacs config and a software project.

If you don't test or incubate features long enough before your workflow depends on them you'll find yourself building atop more bugs.

I find tagging releases of my emacs config useful for this.

Re: Advanced techniques for reducing Emacs startup time

#64

Post by ParetoOptimal »

dilap wrote: post #55
cheesewhizemacs wrote: post #54

Earlier quoted context omitted.

>Everything is always slightly broken all the time; I don't think it's actually humanly possible to fix this -- too many parts. Fix one thing, another thing breaks. Speak for yourself. Just last weekend I had a few hours with little to do, and actually wanted to do some yak shaving on my Emacs config just for the hell of it. but it works too well and I have everything the way I like it! My yak is f*kin' bald, man! No…

Well, I'm jealous! Here's my list of problems to solve on a rainy day†: ;; * kill-word-sp cancels ioccur mode for some reason ;; * after running ipython for a while, all terminal commands hang waiting for output ;; * iedit substition starts just corrupting shit (e.g., try replacing \t with spaces) ;; * "replace-match-maybe-edit: Match data clobbered by buffer modification hooks" ;; * delete-horizontal-space doesn't w…

> ;; * emacs stopped automatically recompiling .emacs wtf

Change to follow XDG specification and ~/.config/emacs having precedence?

Re: Advanced techniques for reducing Emacs startup time

#65

Post by BeetleB »

svnpenn wrote: post #34
nine_k wrote: post #26

I honestly don't understand the point. Emacs (much like VSCode or Idea) is a tool that I use for everything, all day. I don't see a point in shutting it down, except for upgrading the version. Its startup time of, say, 15 or even 30 seconds (if you start many language servers) is only paid once, when I log in. So I run it in server mode, and emacsclient start instantly, as a GUI window, or in a terminal, with all the…

> Its startup time of, say, 15 or even 30 seconds Jesus. I use Gvim, which starts in less than a second. When I'm done editing, I close it. The only app I generally leave open, is browser. How people can justify such awful performance is beyond me, and why I will never, ever use Emacs.

If it's taking 15 seconds to start, it's because the person is doing things with it that Gvim can't do. An empty config probably takes 1s to load.

It's like complaining that it takes 30s to boot your PC when Gvim opens up instantly. It's a silly comparison.

Re: Advanced techniques for reducing Emacs startup time

#66

Post by hsbauauvhabzb »

loloquwowndueo wrote: post #17

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.

Re: Advanced techniques for reducing Emacs startup time

#67

Post by matthews2 »

dilap wrote: post #51
matthews2 wrote: post #44

Earlier quoted context omitted.

Instead of totally killing the garbage collector, you can effectively turn it off during startup by setting gc-cons-threshold to a large number, and then restore it after init. The article touches on this but they don't increase it very much and restore it at the end of init.el (emacs-startup-hook runs later). early-init.el: (setq gc-cons-threshold most-positive-fixnum) (add-hook 'emacs-startup-hook (lambda () (setq…

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?

Re: Advanced techniques for reducing Emacs startup time

#68

Post by dilap »

ParetoOptimal wrote: post #63
dilap wrote: post #33

Earlier quoted context omitted.

Yeah, as soon as you start customizing emacs (which is the whole point of emacs), you run into bugs. Everything is always slightly broken all the time; I don't think it's actually humanly possible to fix this -- too many parts. Fix one thing, another thing breaks. I'm addicted to the flexibility, but I dream of something that offers the same level of flexibility in a more robust ecosystem (e.g. statically typed, stat…

> Yeah, as soon as you start customizing emacs (which is the whole point of emacs), you run into bugs. Everything is always slightly broken all the time; I don't think it's actually humanly possible to fix this -- too many parts. Fix one thing, another thing breaks. There's no difference between an advanced emacs config and a software project. If you don't test or incubate features long enough before your workflow de…

For sure. But I think what's going wrong is a little different.

E.g., there's a mode that highlights the current line. And there's a mode that let's you run a shell inside a buffer.

And for some reason, the current line highlight doesn't work on the most-recent (waiting for input) line.

OK, actually looking at this a little more closely, I think it's because shell mode does some sort of thing where it redefines the "start" of the line to not include the shell prompt, and I guess whatever is doing the line highlighting is using that same notion of "start" of line. So on a line that just contains the prompt, the line highlighter thinks the line is zero length, and highlights nothing.

I think this is typical of lots of emacs problems. You have all these modes that interact w/ each other, w/o strong models of the interactions, so you end up with a bunch of little bugs.

(And because there's combinatorially many different ways you can combine modes, I don't think testing is ever really going to help you here. You just need formal structures and coding styles that guarantee or lend themselves more to correctness.)

Re: Advanced techniques for reducing Emacs startup time

#70

Post by dilap »

ParetoOptimal wrote: post #64
dilap wrote: post #55

Earlier quoted context omitted.

Well, I'm jealous! Here's my list of problems to solve on a rainy day†: ;; * kill-word-sp cancels ioccur mode for some reason ;; * after running ipython for a while, all terminal commands hang waiting for output ;; * iedit substition starts just corrupting shit (e.g., try replacing \t with spaces) ;; * "replace-match-maybe-edit: Match data clobbered by buffer modification hooks" ;; * delete-horizontal-space doesn't w…

> ;; * emacs stopped automatically recompiling .emacs wtf Change to follow XDG specification and ~/.config/emacs having precedence?

Not sure what that means, but I appreciate the response!

It's been a while since I wrote that note to myself, but I somehow had .emacs setup so it'd get recompiled automatically to byte code on changes (which helps startup speed), and somehow whatever I setup at some point stopped working. (Which resulted in my .emacs changes being silently ignored, as stale .elc was used -- that was confusing to figure out!)

For now I just gave up and stopped using the byte-compiled version, sometimes life is too short, even for an emacs user!

(Though in general anyone who chooses to use emacs must not think life is TOO short...)

Post reply on HN