Tuning Your Emacs Configuration for a Fast Load

Gergely Risko has an interesting GitHub repository that explores ways of making your Emacs load time as small as possible. Unless I’m hacking on my configuration, I rarely start Emacs except at boot time so the two or three seconds of startup time doesn’t bother me much. But if you simply must get your startup time to an absolute minimum, take a look at Risko’s strategy.

The TL;DR is that he avoids package-initialize and uses use-package in its place. The real problem with that solution is getting the load paths for the packages. In the video on use-package, John Wiegley and Sacha Chua discuss that problem. Wiegley avoids it by not using the package system. Most of use would rather not take that option and Risko has a method of loading the paths that runs when init.el isn’t compiled and adds them to the init.elc image so that the overhead is mostly avoided.

Most of us, I’m sure, don’t load Emacs very much. We either have a long running instance or start the server and use emacsclient so unless you have a use case like Wiegley’s that requires frequent restarts of Emacs, you may not want to bother with Risko’s solution. If minimizing your Emacs load time is another video game for you, take a look at the repository to see if his ideas might help.

This entry was posted in General and tagged . Bookmark the permalink.
  • Hi Jon. Unintentionally my new game is to increase my Emacs startup time. I
    don’t know why this is happening and I am OK with it, I don’t need to
    investigate.

    ┌────
    │ (emacs-init-time)
    └────

    ┌────
    │ "14.3 seconds"
    └────

    But I am always curious about “the going faster game”. And usually the solution
    here is to start `emacs-server' on boot so it is fast so that you don’t have to
    restart you Emacs. However I have another easier solution which is to startup
    another instance of Emacs so that it doesn’t interfere re with whatever you are
    doing. It doesn’t fix the speed problem. I don’t mind that it takes 14.3
    seconds. But because I’m usually testing tangled files, the flow matters most.

    Here is my command for that on macOS:

    ┌────
    │ alias emacs="open /usr/local/opt/emacs-mac/Emacs.app --new --args $1"
    └────

  • According to my understanding, package-initialize not only setups load-path but also autoloads. I don't like to manage the autoloads manually even with use-package, since in my opinion it's packages authors' job not the users'.

    On my system (Mac), using use-package without byte-compiling is very slow (takes about 7.3 seconds, and more importantly, also have noticeable delay during using Emacs, e.g., first use of helm-M-x), thus I have to byte-compile my init.el (takes about 2.3 seconds).

    • jcs

      One of the reasons Wiegley wrote use-package, he says, is that his autoload file got so large it was taking 30% of his load time. I've converted my entire init.el to use-package and haven't noticed any appreciable change in load time one way or the other and I don't bother byte compiling it. I'm not sure why you're seeing the longer load times.

  • Mattias Bengtsson

    > Most of us, I’m sure, don’t load Emacs very much.

    Do you have any data to back that up?

    • jcs

      No, that's why the "I'm sure." Still, one of the first things I had to overcome when moving from Vim to Emacs was getting away from the Vim workflow of starting the editor when I needed it versus the Emacs way of just leaving the editor running all the time.

      Given that Emacs is slow to start, I can't imagine most people not just leaving it running or using emacsclient. Of course, I could be wrong--it wouldn't be the first time.

  • I ended up using twice the default memory and my Emacs was happy. When I used the max amount it hesitated before doing anything making it slower.