[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Help understanding some bad emacs behavior
From: |
Stefan Monnier |
Subject: |
Re: Help understanding some bad emacs behavior |
Date: |
Sun, 16 Nov 2014 21:10:14 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
> 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