5

I care about the time it takes to start emacs. I bounce around a lot and edit many files. I cannot use emacsclient due to some limitations in my workflow and machine.

  • In the terminal emacs -nw -Q M-x emacs-init-time returns 0.0 seconds
  • In the GUI emacs -Q M-x emacs-init-time returns 0.8 seconds

What is the reason for this discrepancy? Can it be corrected?

  • emacs 24.4.1
  • Arch Linux
PythonNut
  • 10,243
  • 2
  • 29
  • 75
  • `emacs -Q -nw --eval '(kill-emacs)'` and `emacs -Q --eval '(kill-emacs)'` give me 0.04s and 0.35s, a less extreme time. I'd put my money on the creation of the graphical frame and initialization of fonts. – wasamasa Dec 19 '14 at 19:52
  • For me, the `emacs -Q --eval '(kill-emacs)'` incantation takes ~1s to run. – PythonNut Dec 19 '14 at 19:57
  • 8
    Tangentially, you might consider ways to avoid leaving Emacs in the first place, so that rather than starting a new instance to edit a file, you are just visiting the file from inside an already-running instance. If you can get used to using the terminal / shell facilities in Emacs, that's often a big step in this direction. – phils Dec 19 '14 at 21:33
  • 1
    @phils yes, my normal emacs processes are generally long running, but I do a lot of quick work over SSH. I do a _lot_ of shell as well and TTY emacs as a shell just isn't for me (yet). Thus I move around from machine to machine spawning temporary emacs sessions. (Note that on some systems [TRAMP doesn't work](http://emacs.stackexchange.com/questions/5498/get-tramp-working-with-cygwin-sshd)). Also, even on my main machine, I do a lot of emacs development, and I flush my environment pretty often. – PythonNut Dec 20 '14 at 17:07

2 Answers2

4

This delay is likely caused by font initialization, simply because fonts are a major difference between TTY frames and GUI frames: TTY frames don't do any font management—TTYs don't support font selection anyway—whereas GUI frames have a pretty advanced font management.

Try to run your GUI Emacs through strace: You probably see a lot of IO calls on font files. If you do, you can try to reduce the delay by removing fonts, or by trying the unicode-fonts package, which tries to cache a lot of Emacs' font configuration.

If that doesn't work, or if strace shows you no font IO, its output should still provide valueable information.

  • Or if you are running a remote emacs through ssh, emacs will ask the X server for a list of all available fonts on startup, and that takes time – especially if the network is slow. At least, that's what I found when I investigated this years ago. (These days, I am lucky to get away with just a local emacs instance.) – Harald Hanche-Olsen Feb 04 '15 at 08:13
  • That does seem to be it, according to `strace`. I suppose I'll live with it--I don't want to delete my fonts. :) – PythonNut Sep 07 '15 at 23:22
0

I'm not sure you can optimize emacs -Q that much. But if you want to know which packages take time to launch and optimize at this level instead, I strongly advise you to have a look at use-package: https://github.com/jwiegley/use-package.

Damien Cassou
  • 877
  • 4
  • 14
  • That's exactly the problem. I've whittled down my own init to about 1s. Emacs's own startup is actually longer than my own init, sometimes. – PythonNut Feb 03 '15 at 21:41