help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs Slowdown


From: Phillip Lord
Subject: Re: Emacs Slowdown
Date: Wed, 18 Mar 2015 14:13:40 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.90 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>> Apologies if I have not done the right thing here -- I've not written
>> much C nor used gdb before.
>
> Looks useful, thank you.  AFAICT in all those backtraces, Emacs is not
> "busy" but it is simply waiting for input (a process monitor such as
> "top" should be able to confirm that the Emacs process is not using any
> significant amount of CPU at those times).

Oh, sorry, forgot to mention that. Indeed, emacs is not chewing up the
CPU, nor memory. I didn't think to check iotop. I can do that if needed.


> When Emacs feels slow, what happens if you keep typing without waiting
> for Emacs's response?

It catches up eventually. It *seems* to get some keystrokes garbled
(i.e. in the wrong order) although typing without visual feedback is
fairly hard work, so I might just be hitting the wrong keys.

This is up to the point that it dies -- then it seems to really hang
(repaint stops for instance). I've let it alone for several minutes and
get not keypresses at all.



>
>> The last two backtraces are after it
>> has become non-responsive, up till the kill.
>
> The last two backtraces are actually different: Emacs is also waiting
> but it's doing so elsewhere at a spot I find weird (it's actually inside
> an X11 library call waiting for some input event (in "XimRead" the "im"
> stands for "input method"), while in the middle of redrawing part of
> Emacs's display).  I'm not sufficiently familiar with this code to go
> much further with it, so please M-x report-emacs-bug and include the
> last backtrace (the last 2 are identical, AFAICT).
>

Okay, I will do so!


Phil



reply via email to

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