views:

663

answers:

4

I customize Emacs a lot. Recently, I added something to my .emacs configuration that sporadically pegs my CPU at 100%, but I really don't know what it is.

If I press C-g a bunch of times, eventually I'll get a message below the minibuffer asking me if I want to auto save my files and then if I want to abort emacs entirely. If I keep saying no and keeping pressing C-g, eventually I can get back to running emacs as normal. An hour or so later it will happen again.

I could keep going about like I am, commenting out various things I've added recently, restarting emacs, trying to narrow down the culprit, but it's slow going.

Is there a way I can profile emacs directly to figure out what lisp function is hogging the CPU?

+4  A: 

This is not, strictly speaking, an answer to your question, but rather than doing the comment-out-and-restart thing, you can start emacs with the -q option, load your .emacs into a buffer and evaluate each sexpr yourself with C-x C-e to track down the offending one.

Cirno de Bergerac
Good point, I do eval-expression all the time, but this mode of debugging hadn't initially occurred to me.
EnigmaCurry
+6  A: 

Have you tried: Options->Enter debugger on Quit/C-g? (this is on emacs22)

If you need to debug start-up of emacs: use emacs -q --no-site-file, visit your .emacs (or site-start.el or whatever), activate the menu item Options->Enter debugger on Quit/C-g, and then menu item Emacs-Lisp->Evaluate buffer and C-g when it appears to freeze. There may be a easier way of doing this.........

luapyad
+12  A: 

The suggestion of setting debug-on-quit to t so that you can find out what Emacs is up to is a good one.

You can also use the Emacs Lisp Profiler. This is rather under-documented: you'll have to read the comments in elp.el for the details, but basically you run elp-instrument-package to turn on profiling for all the functions with a given prefix, and then elp-results to see the results.

Here's some typical output after typing M-x elp-instrument-package RET c- RET, fontifying 4,000 lines of C, and then running elp-results (and using elp-sort-by-function to sort by call count):

Function Name                  Call Count  Elapsed Time  Average Time
=============================  ==========  ============  ============
c-skip-comments-and-strings    107         0.0           0.0
c-valid-offset                 78          0.0           0.0
c-set-offset                   68          0.031         0.0004558823
c-end-of-macro                 52          0.0           0.0
c-neutralize-CPP-line          52          0.0           0.0
c-font-lock-invalid-string     20          0.0           0.0
c-set-style-1                  19          0.031         0.0016315789
...

In your particular case the profiler doesn't help immediately, because you don't know which package is at fault. But if you can make a guess (or use debug-on-quit to find it for sure) then the profiler can help you diagnose the problem in detail.

Gareth Rees
+1  A: 

With dope.el you can profile entire .emacs or multiple elisp files loaded at startup. Download it from www.gnufans.net/~deego/pub/emacspub/lisp-mine/dope/

M-x dope-quick-start will show a little introduction tutorial.

iiska
Thank you for the dope package. I was able to reconfigure my .emacs to load in less than a second using this package. :)
jinxed_coder