8

I have seen this thread but my problem is an order of magnitude larger. Also, a newbie, I did not understand much of what was being discussed there. So, this new question.

I am running Emacs 25.2.2 on Kubuntu 17.10 on a low-range laptop computer with 4GB RAM. Consider:

user:~/ $ time nvim +qall                                                                          
nvim +qall  0.63s user 0.17s system 86% cpu 0.921 total
user:~/ $ time emacs -nw -kill                                                                     
emacs -nw -kill  81.70s user 9.00s system 93% cpu 1:36.84 total
user:~/ $ time emacs -nw -q -kill                                                                  
emacs -nw -q -kill  0.32s user 0.07s system 10% cpu 3.636 total

Something seems to be grossly wrong with my setup. But I do not know what is it.

So, what do I need to do to bring the start-up time for emacs down to a more reasonable number?

My ~/.emacs file contains several lines. I do not know which ones will be relevant here. So, please ask me and I will edit my question accordingly.

16
  • 3
    Start by bisecting your init file to find which part contributes most to the slowdown. You can also delay or inhibit loading stuff until it's needed (e.g. autoload). If you identify something that you need each time but which causes a significant slowdown, you can profile it to find out whether you can easily improve it - see (elisp) Profiling.
    – Drew
    Commented Mar 17, 2018 at 14:48
  • @Drew I understand the general direction you are hinting at. How do I start emacs logging things as it initializes? This is different from debugging, I guess
    – deshmukh
    Commented Mar 17, 2018 at 15:27
  • Something is definitely wrong. My init files are thousands of lines and load many third party packages but they only take a few seconds to load. If your init file is small, you could post it here.
    – Qudit
    Commented Mar 17, 2018 at 18:08
  • It's not different from debugging; it is debugging. Start by bisecting your init file. You can use comment-region to comment out our uncomment a region of code. This is a binary search - it should quickly tell you which part of your init file is problematic.
    – Drew
    Commented Mar 17, 2018 at 19:52
  • @Drew it turns out that (desktop-save-mode t) was the culprit. That one line commented out brought the start up time down to less than 6s. But now I do not have access to my earlier buffers, etc. How to tame desktop-save-mode or is there an alternative
    – deshmukh
    Commented Mar 18, 2018 at 4:30

4 Answers 4

14

Whatever your .emacs and its improvements, you also should consider running emacs as a server at your session's opening :

emacs --daemon

Now, running emacs with

emacsclient -t

or

emacsclient -nw -c

or ... (see options) will be much faster

2
  • Thanks! This makes it blazing fast. Feels very responsive. BTW, it shows two processes, emacs and emacsclient. Hope that is correct
    – deshmukh
    Commented Mar 20, 2018 at 12:11
  • @deshmukh yes that is correct.
    – icarus
    Commented Mar 20, 2018 at 12:25
8

1) I have found esup to be a very convenient for Emacs startup profiling.

You just run M-x esup and get back list of all expressions in your init.el sorted by the time they took to execute. You don't need to restart Emacs or add anything special to the config, so narrowing on the slow down suspect becomes much easier.

2) I (use-package :defer t) all the things and avoid (require ), so the packages are only loaded when needed.

My issue wasn't as severe as yours, but I went from 7s to 1.7s startup on my old MacBook Air without giving up any of the packages I use.

1
  • Thanks for your answer. Could you expand on how you load packages as they are needed? I don't use use-package. Thanks. Commented Apr 21, 2020 at 8:06
6

Side note, it is generally considered a good idea to have your startup code in ~/.emacs.d/init.el rather than ~/.emacs, one less hiden file in your home directory, a suffix so that other editors can guess the contents....

For bisection, the idea is that you stop running your .emacs about half way and see if it still takes a lot of time. If it does then you know that the problem is in the first half, otherwise you know it is in the second half. You then divide the half that has a problem and stop running half way through that half, so either at the 1/4 or 3/4 mark of the original file. Now you know which quarter (half of a half) is troublesome, so you can break that down into halves and find which eighth is a problem, repeat until you are down to a single function call.

The easiest way to stop running at a point in a file is to add a line

(error "Stopping .emacs")

For profiling the code, you can add

(profiler-start 'cpu)

as the first line of your startup file and add the two lines

(profiler-report)
(profiler-stop)

at the end.

1
  • Thanks. Changed from .emacs to init.el :) One less dot file in ~
    – deshmukh
    Commented Mar 20, 2018 at 12:11
2

My guess is that you have set up Emacs to save your session and have accumulated hundreds of buffers in various modes.

Try C-x C-b and clean up using d (to mark buffers for deletion) and x (to delete buffers marked in that manner).

2
  • @user18816 Yes. You were right. There are literally hundreds of buffers in various modes. C-x C-b d x is going to cumbersome. midnight-mode seems to be a better option.
    – deshmukh
    Commented Mar 20, 2018 at 11:12
  • @deshmukh just in case it is not obvious, you can mark multiple buffers with d and then delete them all with a single x, you don't need to alternate d and x.
    – icarus
    Commented Mar 20, 2018 at 12:37

Your Answer

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

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