[Top][All Lists]

[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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]