On Sun Nov 16 2014 at 8:10:15 PM Stefan Monnier <
address@hidden> wrote:
> Sorry, good point. The emacs process maxes out one of my cores for a few
> minutes. During this time emacs seems unresponsive to input, though it does
> redraw on the screen.
You can try M-x profiler-start RET RET before and M-x profiler-report
RET afterwards, which should tell you where time was spent.
> Maybe the deep-seeming stack of Ffuncall/exec_byte_code/etc. is normal, but
> it was remarkable enough to me that I thought I'd mention it.
Yes, it's perfectly normal. If you think of how an interpreter works,
the C-level backtrace will typically look like a (deep) nesting of calls
between functions called "eval" or "apply" or "call".
> What's the best way to get that? Bear in mind that, as far as I can tell,
> emacs isn't responding to input when I see this problem. And since I don't
> really know where this is happening in elisp-land, I'm not sure where to
> add instrumentation or anything like that.
You can try (setq debug-on-quit t) and hitting C-g.
If that doesn't work, do a "kill -USR2 <emacspid>" which should also
drop you into the debugger.
Stefan