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.

deshmukh
  • 1,852
  • 13
  • 29
  • 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](https://www.gnu.org/software/emacs/manual/html_node/elisp/Profiling.html). – Drew Mar 17 '18 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 Mar 17 '18 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 Mar 17 '18 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 Mar 17 '18 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 Mar 18 '18 at 04:30
  • @Drew Also, should I edit the question to be specific about desktop-save-mode or should I ask a new question? – deshmukh Mar 18 '18 at 04:31
  • Are any of the previous files "remote" – icarus Mar 18 '18 at 04:33
  • @icarus No. All the files reside in my ~ folder. To give you an idea of the size of the desktop file, ~/.emacs.d/.emacs.desktop is a 8,000 line file! – deshmukh Mar 18 '18 at 04:49
  • 8,000 is an impressive number of lines, I only have 32. What is the main thing that is contributing to this size? Do you typically have lots of frames or windows open? Profiling the one line might be interesting. – icarus Mar 18 '18 at 06:19
  • Is that ~8,000 files you're loading? Because that's pretty crazy. Try using `midnight-mode` to keep things more manageable? `M-x customize-group RET midnight RET` for configuration. – phils Mar 18 '18 at 14:09
  • Please ask a new question - about desktop-mode. This question was apparently answered by your bisecting your init file to discover the culprit. But before asking a desktop question, apply the same technique (similar) to that: bisect the problem. Look at your desktop file to see what's there. Try bisecting it. – Drew Mar 18 '18 at 14:13
  • Emacs doesn't recognize "+qall" - you should try `emacs -nw --kill`. What you show here includes time emacs is running after initialization. – mkcms Mar 18 '18 at 18:43
  • @icarus Yes. I open a lot of files so that leads to a lot of windows although it happens in only one frame. But I thought desktop-save-mode should have options to trim buffers opened x days ago, etc. – deshmukh Mar 20 '18 at 08:54
  • @icarus The main thing contributing to the desktop file are buffers – deshmukh Mar 20 '18 at 09:15
  • @phils midnight-mode is extremely helpful. Thanks! And it needed almost no customization. – deshmukh Mar 20 '18 at 11:05
  • @mkcms Thanks for pointing it out. I have edited the question. – deshmukh Mar 20 '18 at 11:08

4 Answers4

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

david
  • 273
  • 3
  • 8
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.

Zaript
  • 81
  • 1
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.

icarus
  • 1,904
  • 1
  • 10
  • 15
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).

  • @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 Mar 20 '18 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 Mar 20 '18 at 12:37