Cool. Can you show how you start an Emacs (i.e., what flags you use) to test whether init.el would load successfully next time an Emacs is started the normal way?
That is your.emacs.d, I presume? I am still mostly carrying around a .emacs and not using init.el.
That said, played with this some today and I see that I can get my startup down to about 5 seconds on my old netbook. Not too bad, all told. (This computer is hilariously slow.)
I've been using Emacs for more than 30 years and my init file is mostly loading and configuring extra packages, and not customizing the editing behavior. I have no problem working in a basic "emacs -q" session (which skips loading the init file) when I don't want to "pollute" my main session (eg. working with huge logs/dumps).
So am I using this dumper system every time I launch emacs? I start emacs "normally" in that I simply launch it from the cmd line with the daemon flag.
I take advantage of the fact that a .emacs file has higher precedence than a .emacs.d/init.el file for this. All the common stuff lives in the .emacs.d directory and is under source control. The little bit of work/machine specific stuff I have goes in the .emacs file, which wraps a
(load "~/.emacs.d/init")
My home machines don't need anything special, so there's no .emacs file and the .emacs.d/init.el file just gets loaded directly.
This is true. I might refactor the codebase to do what you're suggesting in the future.
For now I just pushed a new v1.1.0 release that automatically detects and supports ~/.emacs.el and ~/.emacs.d/init.el in addition to ~/.emacs as configuration file locations.
That should fix this problem for most people for now although I agree that your suggestion is probably more robust overall.
Emacs has two init stages, you only see the latter.
The first is what gets it to the dump file.
The second is where your personal .emacs file gets loaded and executed.
The first is the one that takes too long and motivated them to create the dumper system to begin with, and needs some resolution (elimination and making that first init process faster, switching to a serialization of the objects rather than the C program memory, or something else).
While not in line with the Lisp philosophy, it's far more hygienic to restart Emacs after a configuration change rather than reloading the init file. There's really no way to bring Emacs back to a pre-init state in order to recreate the initialization process. Not to mention that compiling the init file runs different code than loading the init file, and Lisp expressions are far from idempotent, so you can't really be sure your changes work until you restart Emacs anyway.
If you start Emacs with `emacs --no-init-file --no-site-file --no-splash` it starts (especially in non-GUI mode) in a fraction of a second.
If you then write your init file(s) in a certain way (use autoloads) you can maintain this performance while retaining all your customizations.
The reason almost nobody does this, e.g. I don't, my Emacs starts up in many seconds, is because the workflow with Emacs for those who use it is not to be restarting it all the time.
I don't reboot my computer either every time I need to open a new browser tab, and I don't need to restart Emacs every time I need to open a new file, so I really don't care if it takes 10 seconds to start it.
I start emacs once every few weeks, and that's mainly just to do a reset when I finish a project or get to a safe point and want to get a clean slate. The startup time for Emacs is never an issue for me.
This is really “just leave Emacs running all the time,” which is more of a workaround or an acceptance of “fit your workflow around Emacs” than it is truly a solution, which would be to reduce startup times.
reply