6

I am seeing some slowness in my init file loading:

$ time emacs --debug-init -eval '(kill-emacs)' -Q

real    0m0.672s
user    0m0.338s
sys     0m0.057s

$ time emacs --debug-init --eval '(kill-emacs)'

real    4m17.821s
user    0m2.769s
sys     0m0.226s

These 4mins of loading is reproducible. Actually looks like a timeout. It happens when I do (require 'magit). But I don't think it's related to magit because (require 'helm-gtags) causes the same slowness.

However --debug-init is not activated when I press C-g during the time emacs is unresponsive. Obviously is not activated either after the load finishes because there's no error.

I am wondering how I can understand where the slowness comes from. I guess a backtrace at the point of slowness would be nice. Maybe some tracing facility?

Improve this question
5
  • 1
    Please bisect your init file. Alternatively, insert (setq debug-on-quit t) at the top of your init file and hit C-g again when starting Emacs.
    – wasamasa
    Aug 13 '15 at 9:31
  • One thing you can try is running Emacs from within GDB, and hitting C-z at the GDB prompt to inspect the current state. There is a description in this answer.
    – legoscia
    Aug 13 '15 at 9:32
  • What @wasamasa said. And if necessary bisect (a copy of) magit.el. Or helm-gtags.el. IOW, narrow the problem to some actual, small bit of code. Then post here what you find, if the solution is not obvious at that point.
    – Drew
    Aug 13 '15 at 13:29
  • 4
    Wild guess: it looks&smells like recent TRAMP issue (it affects magit, recentf, helm, etc indirectly via TRAMP paths) so add (setq tramp-ssh-controlmaster-options "") at the beginning of your config and try again. If loading is fast now then read lists.gnu.org/archive/html/bug-gnu-emacs/2015-03/msg00389.html “I am wondering how I can understand where the slowness comes from.” You can use strace tool with e.g. “-T” flag to show the execution time of each system call - 16603 read(10, "ssh: connect to host host.does.not.exist port 22: Connection timed out\r\n", 16312) = 72 <18.558404>
    – kmicu
    Aug 14 '15 at 14:44
  • 1
    @kmicu you are bang on the issue. Tramp options solves the problem. If you write that up as an answer I will accept it as the solution. Thanks.
    – Paulo Matos
    Aug 17 '15 at 12:43
7

Thanks to @kmicu for the comment to my post. His answer was correct.

This is a recent TRAMP issue and worked around by adding

(setq tramp-ssh-controlmaster-options "")

to the beginning of my .emacs file. This email thread provides the necessary context.

Improve this answer
2

If you use use-package and set use-package-verbose to t, you can see the load times for packages that take longer than 0.1s.

Unfortunately, you cannot loop over a list of packages to use them.

Improve this answer
0

(Answering the general question on the title of this question)

Try using benchmark-init package. It provides detailed timing information on the package 'require' operations and other load times during Emacs initialization.

Improve this answer
-6

4 mins is too long. I use Emacs23 on netbook (eeepc 701) with 250 packages installed, and the startup time is no more than 20 seconds.

You don't need bisect. The root cause is so obvious. It's simply your using of require everywhere.

don't use (require), use (autoload), check http://www.gnu.org/software/emacs/manual/html_node/elisp/Autoload.html to understand why.

and check https://github.com/purcell/emacs.d for sample setup.

BTW, you can use https://github.com/juergenhoetzel/profile-dotemacs/blob/master/profile-dotemacs.el to measure the startup time.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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