Super fast Emacs start up

Hello. I've just tried dumping my Emacs after it loads packages and is configured. Like this: ``` emacs --batch -l ~/.emacs -eval '(dump-emacs-portable "emacs.dump")' ``` Then I start my already configured Emacs: ``` emacs -q --dump-file emacs.dump ``` Emacs starts a lot faster this way. Why are we Emacs users not taking advantage of this? Or this is well known already? edit: I've followed this to fix the issues with load-path: https://www.reddit.com/r/emacs/comments/2rietp/dumpemacs_truly_speeds_up_emacs_startup/

I don't know if it's *well* known, but it's certainly known (I think it's worth advertising, though). You could dump a custom executable back before the portable dumper too (the build process has always involved a load-and-dump phase), so it's a very old technique in the general sense. Personally I've never bothered outside of experiments because my start times are "fast enough" that I have no particular desire to introduce a new build step after making changes to my config (although one could always automate that part). People new to the concept should have a look at `loadup.el` to see what gets loaded by a standard dump, and refer to `C-h i g (elisp)Building Emacs` for more details.

This is not yet supported with 100% reliability, so expect possible problems.

>Why are we Emacs users not taking advantage of this? Because it's extra work that improves something I rarely need.. On a normal day, I boot up my emacs daemon once and after that, opening new files/frames is pretty much instantaneous and I can just install packages anytime without having to redump... Aliasing emacsclient to open a frame or start a daemon first, if necessary, is less of a hassle to me..

Super-cool! Likely the reason it isn't better known is that people don't start emacs very often. My current emacs session has been running for weeks, since I got my new machine. Before that, I would frequently have sessions up for months at a time.

emacs has a docker built-in :p

Yes, it's known and there was a post on that: [https://archive.casouri.cat/note/2020/painless-transition-to-portable-dumper/index.html](https://archive.casouri.cat/note/2020/painless-transition-to-portable-dumper/index.html) AFAIK, portable dumping with a config is not very reliable. There was an issue that portable dumping did not play nicely with native compilation (aka GccEmacs). I hear the issue has been resolved, but I don't want to deal with several issues that come with pdump. There was another attempt for faster startup time by a hardcore user: [https://gitlab.com/blak3mill3r/emacs-ludicrous-speed](https://gitlab.com/blak3mill3r/emacs-ludicrous-speed). This is technologically great, but I don't find the benefit of adopting the additional complexity for cutting down 0.1-0.2 ms. EDIT: Grammar

My init time is 1 second... why bother.

Thanks for the pointers. Something must be wrong with my Emacs config or my laptop is super slow, as it is not just a matter of cutting down just a few milliseconds in my case. It is much more.

The obsession with Emacs startup time is a bit funny to me because it's very easy to run emacs in server/client mode and thus the startup time barely matters at all as launching new clients feels pretty much instant to me. On top of that my startup time is already around 2 seconds (and I haven't done anything special to try to get it to start faster) and that's a reasonable time for a graphical editor to start even if I wasn't using the daemon feature. For comparison VSCode takes well over 5 seconds on my machine with only a couple of extensions installed.

My Emacs starts in less than 0.25 sec now, but it defers loading of packages, so actually it should take more. With one of the above techniques, your Emacs will have packages *eagerly* preloaded, which can be a boost if you restart Emacs frequently (but deferred loading of packages is what most people do).

I haven't profiled my .emacs, but I think it is a call to package-initialize I have at the top, and I see lots of package loading on init. What do I have to do to try deferred loading?

Because we all start the Emacs server once a month or so, at login, automatically. Even if we imagine that setting this up is costless, a single error would likely waste more of my time than this trick would save me over my lifetime.

If you are using `use-package`, one way is to use `:after` keyword: [https://github.com/jwiegley/use-package#loading-packages-in-sequence](https://github.com/jwiegley/use-package#loading-packages-in-sequence) This largely depends on your config macro (e.g. use-package), so please take a look at some popular config repos. An example is Doom Emacs. It uses several techniques (in [early-init.el](https://github.com/doomemacs/doomemacs/blob/master/early-init.el) and other places) to make Emacs start up faster: [https://github.com/doomemacs/doomemacs/blob/develop/docs/faq.org#how-does-doom-start-up-so-quickly](https://github.com/doomemacs/doomemacs/blob/develop/docs/faq.org#how-does-doom-start-up-so-quickly)

On a side note, the same config starts in 0.4-0.5 sec on an older machine, so it can be partly a hardware problem.

I guess I should get rid of the `require`.

> We all Factually wrong projection. How would you ever know what "all" people / Emacs users do?

Yes, I've observed some differences, something with the load-path, and had to tune a bit my .emacs a bit here and there. But after that, Emacs seems to load perfect and it makes a real difference, at least for my particular setup and hardware.

Thanks.

Doom's startup time is more than enough for me.

You know what he meant. It's not necessary to point out that *not actually all* users do it. His point was good: while the idea has potential, at this time, it's likely that using it would end up causing more trouble than saving time.

using an emacs built with "--with-native-compilation" also seems to offer a speedup.

I've tried it, but didn't do the trick for me.

After reading comments here, seems that Emacs startup speed is not an issue in general. I probably have a misconfigured custom .emacs . So the dump solves the issue for my particular case.

Yes, I've added automation with: ```lisp (defun dump-emacs () "Dump current Emacs config." (interactive) (shell-command "emacs-snapshot --batch -l ~/.emacs -eval '(dump-emacs-portable \"emacs.dump\")'")) ```

Maybe .. but I've just started using this. But I admit it needs some setup first.

His point is moot. I, for example, turn my computer off whenever I don't need it. We already have too much global warming. This habit of people that say all the time "The issue that you seem to have is actually not an issue because I say so" are in a way arrogant. Whenever someone writes here something about the startup time, there is *always* a chorus that wants to dictate how to use Emacs.

I honor all the work OP and others are doing to make EMacs start up “fast.” But is it “slow?” When I start it up, typically with my first file to edit as the only parameter, it’s all up and ready to go within a second. How long is the load time for others to make time spent optimizing worthwhile?

I think it an issue with non-doom emacs.ds. mine has never taken less than 7 seconds to start up. The reason why it is not a priority to fix for me is because I start Emacs using systemd with linger enabled so it starts even before I log in to my machine. An additional benefit of using systemd is that you may use unit templates t start several emacs daemons for different contexts ej. Gnus in a separate Emacs

It is not like that for me. Perhaps it's me to blame, as my config is not perfectly tuned, or my hardware.

Honestly I have no idea how configuration works, and just roll out the server on boot and connect via client. Emacsclient doesn't take long for me

[My Emacs](https://github.com/Crandel/home/tree/master/.config/emacs) start up time is less than second without daemon mode

For me Emacs starts in <0.5s s with ~30 external packages (including Evil). The approach to keeping it quick has been the GC startup "trick" and lazy loading with use-package. Using my own theme also helps since is not covering faces for every popular package out there.

I would need to have some feedback from other users before I tried this because a working Emacs is most important to me. My Emacs starts up under 1 second on Linux and so it is not an issue for me. However, I want to thank the OP for bringing our attention to another way of speeding up Emacs.

`require` is eager loading, which would have a performance impact.

I was about to say the same. I also set the daemon as a startup script so I never experience the initial startup lag

I have emacs and edit aliased to `emacsclient -a ""` which does the right thing, whatever the situation :) So the first start will take like 3-5 seconds, which is still acceptable, even if I started a new instance for every file, but immediately is always better than having to wait :D

You should check Doom's or Spacemacs docs on the optimizations they do. That coupled with native compilation in the 28.x series, makes my Spacemacs really fast.

Modern computers are able to ‘hibernate’. Turning your computer off *increases* your energy consumption.

[removed]

Your oneliner is disappearing on my webview. (defun dump-emacs () "Dump current Emacs config." (interactive) (shell-command "emacs-snapshot --batch -l ~/.emacs -eval '(dump-emacs-portable \"emacs.dump\")'")) I thought code-fences worked on Reddit too.

https://git.savannah.gnu.org/cgit/emacs.git/log/?showmsg=1&qt=grep&q=pdumper it's in active development, so it should improve.

Is this still not work with native compile?

Did not work for me with native.

What does dump mean in this context? Non programmer here.

The current state of the program (Emacs) is serialized to a file on disk. To start Emacs after that, the program state is restored from that file. It is a fast operation, because it is more or less the copying of memory. Think of hibernation in operating systems.

I see. What could go wrong? It's not initializing from scratch but restarting from a previous point... ?

Emacs is restored from a previous point, the point after all packages have been loaded and configured, which is the process that takes time if you start from scratch. It seems that the dump process is not entirely reliable at the moment. I don't know the reason. For example, the load-path variable is not restored correctly, and that causes problems. But .. after fixing that, it works perfectly, in my experience at least.

[deleted]