Strange slowness when killing words interactively

Strange slowness when killing words interactively

[Taylor Venable]

Hi, I'm having a strange problem with C-<backspace>
(backward-kill-word) and looking for some help in trying to debug it.
When I use this keystroke, the CPU usage spikes. The same goes for
C-<delete> (forward-kill-word) or any other key that I bind to either
of these functions. Other functions, such as backward-kill-sexp and
backward-kill-sentence, are similarly problematic. As a result, when I
hold the key down, my high repeat rate makes Emacs unresponsive for a
second until whatever is slowing down catches up. It happens with the
GTK GUI, but not with the text user interface. None of my other
machines have this behaviour with the same version of Emacs (that
includes one machine which is running the same distribution [Arch
Linux] with the same packages). No other programs on this system are
affected by performance problems when deleting words of text from a
block. The problem occurs with and without using -q. There does not
seem to be the same problem if I run the kill function itself with
C-u; for example, C-u 1000 backward-kill-word is instant. What's the
best way to profile this and figure out where my CPU cycles are being
eaten? Thanks for any help, my version information is below. I built
from fully updated bzr trunk tonight.

M-x emacs-version
GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.1) of
2011-04-26

gcc --version
gcc (GCC) 4.6.0 20110415 (prerelease)

uname -a
Linux system76 2.6.38-ARCH #1 SMP PREEMPT Sun Apr 17 15:18:58 CEST
2011 x86_64 Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz GenuineIntel
GNU/Linux

-- 
Taylor C. Venable
http://metasyntax.net/

Re: Strange slowness when killing words interactively

[Taylor Venable]

On Tue, Apr 26, 2011 at 21:30, Taylor Venable <taylor@metasyntax.net> wrote:
> Hi, I'm having a strange problem with C-<backspace>
> (backward-kill-word) and looking for some help in trying to debug it.
> When I use this keystroke, the CPU usage spikes. The same goes for
> C-<delete> (forward-kill-word) or any other key that I bind to either
> of these functions. Other functions, such as backward-kill-sexp and
> backward-kill-sentence, are similarly problematic. As a result, when I
> hold the key down, my high repeat rate makes Emacs unresponsive for a
> second until whatever is slowing down catches up. It happens with the
> GTK GUI, but not with the text user interface. None of my other
> machines have this behaviour with the same version of Emacs (that
> includes one machine which is running the same distribution [Arch
> Linux] with the same packages). No other programs on this system are
> affected by performance problems when deleting words of text from a
> block. The problem occurs with and without using -q. There does not
> seem to be the same problem if I run the kill function itself with
> C-u; for example, C-u 1000 backward-kill-word is instant. What's the
> best way to profile this and figure out where my CPU cycles are being
> eaten? Thanks for any help, my version information is below. I built
> from fully updated bzr trunk tonight.
>
> M-x emacs-version
> GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.1) of
> 2011-04-26
>
> gcc --version
> gcc (GCC) 4.6.0 20110415 (prerelease)
>
> uname -a
> Linux system76 2.6.38-ARCH #1 SMP PREEMPT Sun Apr 17 15:18:58 CEST
> 2011 x86_64 Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz GenuineIntel
> GNU/Linux

(Adding emacs-devel since I've started looking at the source code.)

I've found the location where the slowness creeps into kill-word and
friends. Looking at kill-region in simple.el, the part that is very
slow for my system is adding to the kill ring. If I comment those
lines out (as shown in http://paste.lisp.org/+2LWP) then the sluggish
response disappears. It's odd to me that I don't see this behaviour
when I start Emacs with -nw as I would (perhaps naively) think that
slowness in kill-region would be independent of what user interface is
active.

-- 
Taylor C. Venable
http://metasyntax.net/

Re: Strange slowness when killing words interactively

[Chong Yidong]

Taylor Venable <taylor@metasyntax.net> writes:

> I've found the location where the slowness creeps into kill-word and
> friends. Looking at kill-region in simple.el, the part that is very
> slow for my system is adding to the kill ring. If I comment those
> lines out (as shown in http://paste.lisp.org/+2LWP) then the sluggish
> response disappears. It's odd to me that I don't see this behaviour
> when I start Emacs with -nw as I would (perhaps naively) think that
> slowness in kill-region would be independent of what user interface is
> active.

On a graphical terminal, kill-new calls interprogram-cut-function to set
the clipboard (or the X selection, for Emacs 23).  That may be causing
the slowdown.  Could you set interprogram-cut-function to nil and see if
it makes any difference?  If so, we need to figure out why
interprogram-cut-function is slow on your computer.

Re: Strange slowness when killing words interactively

[Taylor Venable]

On Sun, May 1, 2011 at 21:13, Chong Yidong <cyd@stupidchicken.com> wrote:
> Taylor Venable <taylor@metasyntax.net> writes:
>
>> I've found the location where the slowness creeps into kill-word and
>> friends. Looking at kill-region in simple.el, the part that is very
>> slow for my system is adding to the kill ring. If I comment those
>> lines out (as shown in http://paste.lisp.org/+2LWP) then the sluggish
>> response disappears. It's odd to me that I don't see this behaviour
>> when I start Emacs with -nw as I would (perhaps naively) think that
>> slowness in kill-region would be independent of what user interface is
>> active.
>
> On a graphical terminal, kill-new calls interprogram-cut-function to set
> the clipboard (or the X selection, for Emacs 23).  That may be causing
> the slowdown.  Could you set interprogram-cut-function to nil and see if
> it makes any difference?  If so, we need to figure out why
> interprogram-cut-function is slow on your computer.

Indeed, setting interprogram-cut-function to nil improves the speed
dramatically to the normal levels that I see on other machines and in
the console. The default value is x-select-text. The problem is also
fixed by setting x-select-enable-clipboard to nil.

I put my xorg log file on my website if it can be of any help:
http://metasyntax.net/Xorg.0.log

Thanks,

-- 
Taylor C. Venable
http://metasyntax.net/