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
Improve this question
4
  • 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, 2014 at 19:52
  • For me, the emacs -Q --eval '(kill-emacs)' incantation takes ~1s to run.
    – PythonNut
    Dec 19, 2014 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, 2014 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). Also, even on my main machine, I do a lot of emacs development, and I flush my environment pretty often.
    – PythonNut
    Dec 20, 2014 at 17:07

2 Answers 2

Reset to default
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.

Improve this answer
2
  • 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 4, 2015 at 8: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 7, 2015 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.

Improve this answer
1
  • 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 3, 2015 at 21:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.