applying some commonly-recommended optimizations, you can shave Emacs init time to about 2 seconds, from whatever your previous init time was (7 in my case, but I also read about 60s -> 2s improvements).
Init time alone greatly affects how a given system is perceived.
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.
> 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.
Sure thing, but most real-world setups have multiple heavy packages installed.
> If you then write your init file(s) in a certain way (use autoloads) you can maintain this performance while retainng all your customization.
Worth noting that autoloading is useful up to a point - after a threshold, the gains are only theoretical (your reported startup was 0.1s, but immediately after Emacs startup, it froze 2 seconds because all the autoloads are now doing its work).
In the end when I open Emacs I want a bunch of stuff to happen (open files, color them with syntax, etc) - some work has to be performed sooner or later.
> the workflow with Emacs for those who use it is not to be restarting it all the time.
I start it a few times a day, for not accumulating state, particularly that related with Clojure nREPL connections. Not a costly operation.
> most real-world setups have multiple heavy packages installed.
Sure, I wouldn't use it in this mode, but this line to the effect of "it takes seconds to start up" is usually uttered by people who are more used to the likes of nano or vi. You can also use those command-line options to start Emacs in that sort of one-off mode.
> your reported startup was 0.1s, but immediately after Emacs startup, it froze 2 seconds.
That's odd, I can start `emacs --no-init-file --no-site-file --no-splash -nw <file>` and write something to the file, C-x C-s C-x C-c to write + exit with no more noticeable delay than doing the same with mg, nano or vim on my system. This is with Emacs 25.2.2.
> I want a bunch of stuff to happen (open files, color them with syntax.
Opening a file to have it syntax-colored takes less than second (feels like at most 1/8 of second) in that mode.
> I start it a few times a day[...]
Doesn't Clojure have some equivalent of M-x tramp-cleanup-all-connections? Occasionally I'll mass-close buffers, but the uptime of Emacs tends to be 1=1 my laptop, usually about a month (for security updates and the like).
I believe this mode of use is more typical than restarting it this often.
> That's odd...
I meant, for regular usage (with full packages), some people might pride themselves over a 0.1 startup, but then as soon as Emacs does something useful it will freeze a little.
> Opening a file...
Maybe my example wasn't clear enough. When I open Emacs a lot of functionality will be 'there', as it happens with an IDE. Think of a project tree, terminal, misc functionality, and unavoidable dependencies.
> Doesn't Clojure...
The Clojure(Script) tooling stack has many layers from different authors, so it's reasonable to not trust things to work after several connect/disconnect cycles.
Users who want fast startup simply load emacs-server once on system startup and run the emacsclient when needed. Emacs starts in a jiffy when done this way. Of course this probably will not help you with resetting accumulated states.
My emacs gets restarted when my laptop reboots. Which happens on a timescale of months. I honestly don't care if it takes minutes to start, so long as it's super responsive once it's running.
I feel like maybe something's been missed if you're starting emacs all the time. But then, I feel the same way about Linux, and clearly many many people disagree with me.
So the comment in that thread about AOT compilation was extra interesting for me :-)
It’s worth noting that Emacs’ built in lisp libraries are sort-of aot compiled: Emacs loads all the Lisp into memory, evaluating some initialisation stuff, then it does a gc, then it does a very scary “unexec” operation which has been in the source for around 30 years with most people so scared of the function that they only poke at it enough to make it just-about work. The function takes the current contents of memory and produces an ELF from it which will start up with the lisp libraries already loaded into memory.
There's a WIP portable dumper that hasn't been merged yet which'll replace that. This LWN article has a good summary of it: https://lwn.net/Articles/707615/
On the other hand one I don’t really care about init time at all and I think many users don’t care for the same reason. I start Emacs after a reboot (roughly once every three weeks) so even if it takes a minute to start, I would be optimising ~0.01% of my Emacs-using time. If it took ~60s and I reduced that to 2s then this optimisation would save less than 1.5hours over five years. But also that Emacs-starting time is spent reading email not waiting for Emacs so it wouldn’t bother me much if it took ~10min
Probably there's two kind of devs (none being 'superior'): those who are paranoid about keeping things stateless, and those who don't.
A clear example being restarting your computer. Sometimes I do it for no good reason other than knowing that state will be pristine when next time I boot it.
As far as I know, things like: changing gc-cons-threshold, setting file-name-handler-alist to nil, adjusting some jit-lock-* values. And using deferred package loading.
The extreme version is to reproduce a step from building Emacs where you produce a binary with the libraries you want already loaded into memory. This is like making a lisp-image except the image also includes a big C text editor
Doing this requires various security features that operating systems have gained since the 1980s to be turned off so it’s not super advisable if you can avoid it
applying some commonly-recommended optimizations, you can shave Emacs init time to about 2 seconds, from whatever your previous init time was (7 in my case, but I also read about 60s -> 2s improvements).
Init time alone greatly affects how a given system is perceived.