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/

Re: Strange slowness when killing words interactively

[David De La Harpe Golden]

On 02/05/11 05:25, Taylor Venable wrote:

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


Just in case:

Is your emacs running on the same machine as the x11 server, or
remotely?

Are you running a clipboard daemon (e.g. kde klipper, xfce4-clipman) in
your desktop environment? Typically such a thing shows up as a little
clipboard icon in the system tray, with a click on it maybe showing a
history of previous clipboard contents, a bit like a system-wide
kill-ring.  They can in theory cause some slowness by eagerly grabbing
clipboard contents (and sometimes primary selection too) for history
keeping purposes. It's not usually perceptible when everything's local,
though.  If you find such a daemon running, please try temporarily
disabling it and retesting (you'll still have basic clipboard
functionality without the daemon).

Probably you'd have already mentioned if you were seeing similar
symptoms in non-emacs applications that interact with the x11
clipboard, but if you have the "xclip" command line tool available
(arch extra package xclip, apparently), you also could see if the
following is near instantaneous (it really should be):

$ echo 'Hello, World.' | xclip -selection clipboard
$ xclip -selection clipboard -o
Hello, World.

Re: Strange slowness when killing words interactively

[Taylor Venable]

On Mon, May 2, 2011 at 12:32, David De La Harpe Golden
<david@harpegolden.net> wrote:
> Is your emacs running on the same machine as the x11 server, or
> remotely?

Same machine.

> Are you running a clipboard daemon (e.g. kde klipper, xfce4-clipman) in
> your desktop environment?

Nope.

> Probably you'd have already mentioned if you were seeing similar
> symptoms in non-emacs applications that interact with the x11
> clipboard, but if you have the "xclip" command line tool available
> (arch extra package xclip, apparently), you also could see if the
> following is near instantaneous (it really should be):

I haven't noticed it, but it's more difficult to do such a rapid
succession of copy-to-clipboard operations in any other program I can
think of. Using xclip 1000 times in a tight loop in bash takes 2.2
seconds on the machine in question (where Emacs is slow, Core i7) and
6.4 seconds on my laptop (where Emacs works as expected, Core 2 Duo).
Both machines run updated Arch installations, so same version of X11
and whatnot.

Thanks,

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

Re: Strange slowness when killing words interactively

[David De La Harpe Golden]

On 03/05/11 02:14, Taylor Venable wrote:

>> Are you running a clipboard daemon (e.g. kde klipper, xfce4-clipman) in
>> your desktop environment?
>
> Nope.

I'm actually kinda out of ideas if it's not a rogue daemon.

> Both machines run updated Arch installations, so same version of X11
> and whatnot.

Unless someone else has a better idea, one thing that might be worth a 
shot if you have the time is to do a  emacs build from source with:

./configure CFLAGS="-DTRACE_SELECTION"

and then launch emacs -Q 2>/tmp/selection.log and do one or two 
clipboard-hitting operations.  This is liable to produce voluminous 
output, but the log might reveal some shenanigans afoot.

Re: Strange slowness when killing words interactively

[Stephen J. Turnbull]

David De La Harpe Golden writes:
 > On 03/05/11 02:14, Taylor Venable wrote:
 > 
 > >> Are you running a clipboard daemon (e.g. kde klipper, xfce4-clipman) in
 > >> your desktop environment?
 > >
 > > Nope.
 > 
 > I'm actually kinda out of ideas if it's not a rogue daemon.

Is there any chance he's using Motif?  The Motif clipboard protocol is
capable of producing delays that even the US immigration service would
envy.

Re: Strange slowness when killing words interactively

[Taylor Venable]

On Tue, May 3, 2011 at 01:12, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> David De La Harpe Golden writes:
>  > On 03/05/11 02:14, Taylor Venable wrote:
>  >
>  > >> Are you running a clipboard daemon (e.g. kde klipper, xfce4-clipman) in
>  > >> your desktop environment?
>  > >
>  > > Nope.
>  >
>  > I'm actually kinda out of ideas if it's not a rogue daemon.
>
> Is there any chance he's using Motif?  The Motif clipboard protocol is
> capable of producing delays that even the US immigration service would
> envy.

No, this is using the GTK interface. :-)

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

Re: Strange slowness when killing words interactively

[David De La Harpe Golden]

On 03/05/11 12:51, Taylor Venable wrote:

>
>> Is there any chance he's using Motif?  The Motif clipboard protocol is
>> capable of producing delays that even the US immigration service would
>> envy.
>
> No, this is using the GTK interface. :-)

You mean emacs itself? It's more if you were running emacs on a 
motif/cde desktop (or maybe just one with an xclipboard hanging about).

** What desktop environment (KDE, GNOME, XFCE, etc.), if any, are you using?

** Come to think of it, what does this:
(x-selection-exists-p 'CLIPBOARD_MANAGER)
return in your emacs?

GNOME - and apparently now recent XFCE - do actually have tiny clipboard 
managers by default (embedded in gnome-settings-daemon and 
xfce4-settings-helper respectively), but AFAIUI they shouldn't be 
problematic like motif-era ones: Nowadays there is a protocol [1] for 
clients to ask a clipboard manager only at client exit time to copy the 
clipboard content and take over clipboard ownership from the client, to 
persist the clipboard after client exit, and those managers are about 
supporting those clients.  I only recently learned of the XFCE one and 
haven't really looked at it yet, though.

Actually, I think emacs is not doing its part of [1], though it 
shouldn't typically have negative effects except when you try to paste 
after copying in emacs and then quitting, so not directly related to 
your problem.  But I'm now looking at that "Clipboard managers are 
encouraged to use this information to support legacy clients" line in 
[1] - maybe there might be a clipboard manager out there that grabs 
clipboard contents from "legacy clients" eagerly but avoids pestering 
the clients that indicate their support of the spec. That would mean 
even "legacy client" clipboard contents wouldn't lost when they exit 
...but "legacy client" performance would be degraded.

[1] http://www.freedesktop.org/wiki/ClipboardManager

Re: Strange slowness when killing words interactively

[Taylor Venable]

On Wed, May 4, 2011 at 01:36, David De La Harpe Golden
<david@harpegolden.net> wrote:
> On 03/05/11 12:51, Taylor Venable wrote:
>> No, this is using the GTK interface. :-)
>
> You mean emacs itself? It's more if you were running emacs on a motif/cde
> desktop (or maybe just one with an xclipboard hanging about).

Ah, yes; I meant that I'm using the Emacs GTK GUI.

> ** What desktop environment (KDE, GNOME, XFCE, etc.), if any, are you using?

XFCE 4.8.0

> ** Come to think of it, what does this:
> (x-selection-exists-p 'CLIPBOARD_MANAGER)
> return in your emacs?

t

> GNOME - and apparently now recent XFCE - do actually have tiny clipboard
> managers by default (embedded in gnome-settings-daemon and
> xfce4-settings-helper respectively), but AFAIUI they shouldn't be
> problematic like motif-era ones: Nowadays there is a protocol [1] for
> clients to ask a clipboard manager only at client exit time to copy the
> clipboard content and take over clipboard ownership from the client, to
> persist the clipboard after client exit, and those managers are about
> supporting those clients.  I only recently learned of the XFCE one and
> haven't really looked at it yet, though.

That appears to be the case here, the sort-of hidden clipboard manager
in XFCE, because there do not appear to be any separate processes
running that are related to clipboard management.

> Actually, I think emacs is not doing its part of [1], though it shouldn't
> typically have negative effects except when you try to paste after copying
> in emacs and then quitting, so not directly related to your problem.  But
> I'm now looking at that "Clipboard managers are encouraged to use this
> information to support legacy clients" line in [1] - maybe there might be a
> clipboard manager out there that grabs clipboard contents from "legacy
> clients" eagerly but avoids pestering the clients that indicate their
> support of the spec. That would mean even "legacy client" clipboard contents
> wouldn't lost when they exit ...but "legacy client" performance would be
> degraded.

I did just try firing up FVWM to check it out, and Emacs performs at
high speed there, no problems. So the problem may very well be related
to XFCE, or how Emacs interacts with XFCE.

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

Re: Strange slowness when killing words interactively

[David De La Harpe Golden]

[-- Attachment #1: Type: text/plain, Size: 4051 bytes --]

On 07/05/11 03:52, Taylor Venable wrote:
>
> XFCE 4.8.0
>

> That appears to be the case here, the sort-of hidden clipboard manager
> in XFCE, because there do not appear to be any separate processes
> running that are related to clipboard management.


Now running XFCE 4.8.0 from debian unstable here. So much for "shouldn't 
be problematic".

xfce4-settings-helper's embedded clipboard manager is indeed eagerly 
making a copy on every change.  At least it's not eagerly nabbing 
clipboard ownership, like something from the motifozoic. But it seems to 
convert nearly every target every time. o_O (See attached 
emacs_xfce_clipboard_1.log, jut killing the word "This" and then 
"buffer" from *scratch* with two consecutive M-d presses).

** As an immediate workaround, you could pause (kill -STOP/-CONT) or 
kill outright the problem xfce4-settings-helper daemon when using emacs, 
though that's hardly a good solution.

And it looks like it is somewhat eagerly doing it for primary too - 
though it seems to only go after UTF8_STRING in that case, and may have 
some band-aid idle timer. (See attached emacs_xfce_primary_1.log, just a 
C-SPC and then sedately moving right to select the word "notes" in 
*scratch*) (The spec is currently silent on primary - although it seems 
very reasonable to me to expect a PRIMARY_MANAGER and even 
SECONDARY_MANAGER by the obvious analogy with CLIPBOARD_MANAGER, that 
doesn't seem to be actually written down anywhere, nor implemented)

For emacs' part, it is doing the right thing by reacquiring on each 
change.[1] Though emacs needs to do more to comply fully with the spec, 
I suspect it won't help - Still, it might be worth checking to see if 
XFCE stops its nasty behaviour if emacs is patched to support (or claim 
to support) SAVE_TARGETS, just in case XFCE is only doing it for 
spec-unaware clients as previously speculated about (actually, XFCE has 
sources available, I suppose I could just go look).

** But after checking that, really only remains raising a bug report for 
XFCE. This won't really be affecting emacs only, it's just relatively 
noticeable in the emacs case.

The GNOME one is not actually completely free of overhead, but it's much 
more minor. gnome-settings-daemon from GNOME 2.30 on my system is 
repeatedly asking emacs for TARGETS (perhaps it's worried about the 
metadata change as per [1] even if it knows better than to grab the 
entire clipboard content each change), but that is a small constant 
overhead, not a problem compared to the large increasing overheard 
xfce4-settings-helper can generate, certainly low enough that I didn't 
notice until just now when I logged it. (see attached 
emacs_gnome_clipboard_1.log, killing "This" and then "buffer" from 
*scratch* with two consecutive M-d presses).

So I guess XFCE's xfce4-settings-helper implementation was not actually 
based on GNOME's example and there was some slight misunderstanding on 
the XFCE side.  Though I suppose they could have made a deliberate 
decision to work that way, so that even spec-unaware clients' clipboards 
(and primaries) got persisted after exit as previously discussed, even 
if it's at IMO rather too high a price. But if that's so, maybe they 
would still be willing to at least not do it for obviously spec-aware 
clients (if they're not already not doing it in that case, as above I 
haven't checked yet), and then, um, we'd just have to modify emacs to 
comply with the client-side of the spec, which would be a good thing anyway.

Of course under either desktop environment, if you instead run a full 
history-keeping clipboard manager, it will end up eagerly making copies, 
but that's a tradeoff a user usually chooses to make by running such a 
thing. (I have some vague ideas for making them more efficient, but that 
would have to wait until I have a /lot/ of free time...)


[1] http://www.freedesktop.org/wiki/ClipboardManager
"""clipboard owners should reacquire the clipboard whenever the content 
or metadata (e.g the list of supported targets) changes."""



[-- Attachment #2: emacs_xfce_clipboard_1.log --]
[-- Type: text/x-log, Size: 6165 bytes --]

8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30728809
8577:  XInternAtom LENGTH
8577:  XInternAtom FILE_NAME
8577:  XInternAtom CHARACTER_POSITION
8577:  XInternAtom LINE_NUMBER
8577:  XInternAtom COLUMN_NUMBER
8577:  XInternAtom OWNER_OS
8577:  XInternAtom HOST_NAME
8577:  XInternAtom USER
8577:  XInternAtom CLASS
8577:  XInternAtom NAME
8577: CLIPBOARD, target TARGETS (1)
8577: Sending all 76 bytes
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30728828
8577: CLIPBOARD, target TIMESTAMP (2)
8577: Sending all 4 bytes
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30728831
8577: CLIPBOARD, target TEXT (3)
8577: Sending all 4 bytes
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30728832
8577: CLIPBOARD, target COMPOUND_TEXT (4)
8577: Sending all 4 bytes
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30728833
8577: CLIPBOARD, target STRING (5)
8577: Sending all 4 bytes
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30728835
8577: CLIPBOARD, target UTF8_STRING (6)
8577: Sending all 4 bytes
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30728836
8577: XGetAtomName --> LENGTH
8577: CLIPBOARD, target LENGTH (7)
8577: Sending all 4 bytes
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30728837
8577: XGetAtomName --> FILE_NAME
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30728838
8577: XGetAtomName --> CHARACTER_POSITION
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30728840
8577: XGetAtomName --> LINE_NUMBER
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30728841
8577: XGetAtomName --> COLUMN_NUMBER
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30728842
8577: XGetAtomName --> OWNER_OS
8577: CLIPBOARD, target OWNER_OS (8)
8577: Sending all 9 bytes
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30728843
8577: XGetAtomName --> HOST_NAME
8577: CLIPBOARD, target HOST_NAME (9)
8577: Sending all 23 bytes
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30728845
8577: XGetAtomName --> USER
8577: CLIPBOARD, target USER (10)
8577: Sending all 24 bytes
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30728846
8577: XGetAtomName --> CLASS
8577: CLIPBOARD, target CLASS (11)
8577: Sending all 5 bytes
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30728847
8577: XGetAtomName --> NAME
8577: CLIPBOARD, target NAME (12)
8577: Sending all 5 bytes
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30728849
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30728850
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30729910
8577:  XInternAtom LENGTH
8577:  XInternAtom FILE_NAME
8577:  XInternAtom CHARACTER_POSITION
8577:  XInternAtom LINE_NUMBER
8577:  XInternAtom COLUMN_NUMBER
8577:  XInternAtom OWNER_OS
8577:  XInternAtom HOST_NAME
8577:  XInternAtom USER
8577:  XInternAtom CLASS
8577:  XInternAtom NAME
8577: CLIPBOARD, target TARGETS (13)
8577: Sending all 76 bytes
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30729913
8577: CLIPBOARD, target TIMESTAMP (14)
8577: Sending all 4 bytes
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30729914
8577: CLIPBOARD, target TEXT (15)
8577: Sending all 11 bytes
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30729914
8577: CLIPBOARD, target COMPOUND_TEXT (16)
8577: Sending all 11 bytes
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30729915
8577: CLIPBOARD, target STRING (17)
8577: Sending all 11 bytes
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30729917
8577: CLIPBOARD, target UTF8_STRING (18)
8577: Sending all 11 bytes
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30729918
8577: XGetAtomName --> LENGTH
8577: CLIPBOARD, target LENGTH (19)
8577: Sending all 4 bytes
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30729919
8577: XGetAtomName --> FILE_NAME
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30729920
8577: XGetAtomName --> CHARACTER_POSITION
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30729922
8577: XGetAtomName --> LINE_NUMBER
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30729923
8577: XGetAtomName --> COLUMN_NUMBER
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30729924
8577: XGetAtomName --> OWNER_OS
8577: CLIPBOARD, target OWNER_OS (20)
8577: Sending all 9 bytes
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30729925
8577: XGetAtomName --> HOST_NAME
8577: CLIPBOARD, target HOST_NAME (21)
8577: Sending all 23 bytes
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30729927
8577: XGetAtomName --> USER
8577: CLIPBOARD, target USER (22)
8577: Sending all 24 bytes
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30729928
8577: XGetAtomName --> CLASS
8577: CLIPBOARD, target CLASS (23)
8577: Sending all 5 bytes
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30729929
8577: XGetAtomName --> NAME
8577: CLIPBOARD, target NAME (24)
8577: Sending all 5 bytes
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30729930
8577: x_handle_selection_event
8577: x_handle_selection_request, from=0x01c0001f time=30729932

[-- Attachment #3: emacs_xfce_primary_1.log --]
[-- Type: text/x-log, Size: 795 bytes --]

8653: x_handle_selection_event
8653: x_handle_selection_request, from=0x01c0001f time=31171410
8653: PRIMARY, target UTF8_STRING (1)
8653: Sending all 1 bytes
8653: x_handle_selection_event
8653: x_handle_selection_request, from=0x01c0001f time=31172636
8653: PRIMARY, target UTF8_STRING (2)
8653: Sending all 2 bytes
8653: x_handle_selection_event
8653: x_handle_selection_request, from=0x01c0001f time=31173630
8653: PRIMARY, target UTF8_STRING (3)
8653: Sending all 3 bytes
8653: x_handle_selection_event
8653: x_handle_selection_request, from=0x01c0001f time=31174518
8653: PRIMARY, target UTF8_STRING (4)
8653: Sending all 4 bytes
8653: x_handle_selection_event
8653: x_handle_selection_request, from=0x01c0001f time=31175091
8653: PRIMARY, target UTF8_STRING (5)
8653: Sending all 5 bytes

[-- Attachment #4: emacs_gnome_clipboard_1.log --]
[-- Type: text/x-log, Size: 890 bytes --]

9892: x_handle_selection_event
9892: x_handle_selection_request, from=0x012000bb time=33907182
9892:  XInternAtom LENGTH
9892:  XInternAtom FILE_NAME
9892:  XInternAtom CHARACTER_POSITION
9892:  XInternAtom LINE_NUMBER
9892:  XInternAtom COLUMN_NUMBER
9892:  XInternAtom OWNER_OS
9892:  XInternAtom HOST_NAME
9892:  XInternAtom USER
9892:  XInternAtom CLASS
9892:  XInternAtom NAME
9892: CLIPBOARD, target TARGETS (1)
9892: Sending all 76 bytes
9892: x_handle_selection_event
9892: x_handle_selection_request, from=0x012000bb time=33908020
9892:  XInternAtom LENGTH
9892:  XInternAtom FILE_NAME
9892:  XInternAtom CHARACTER_POSITION
9892:  XInternAtom LINE_NUMBER
9892:  XInternAtom COLUMN_NUMBER
9892:  XInternAtom OWNER_OS
9892:  XInternAtom HOST_NAME
9892:  XInternAtom USER
9892:  XInternAtom CLASS
9892:  XInternAtom NAME
9892: CLIPBOARD, target TARGETS (2)
9892: Sending all 76 bytes

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #5: emacs_gnome_primary_1.log --]
[-- Type: text/x-log; name="emacs_gnome_primary_1.log", Size: 0 bytes --]

Re: Strange slowness when killing words interactively

[David De La Harpe Golden]

On 09/05/11 02:18, David De La Harpe Golden wrote:
> modify emacs to comply with the client-side of the spec,
> which would be a good thing anyway.

I've filed this part taken on its own as emacs bug #8641
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8641

Re: Strange slowness when killing words interactively

[Taylor Venable]

On Sun, May 8, 2011 at 23:08, David De La Harpe Golden
<david@harpegolden.net> wrote:
> On 09/05/11 02:18, David De La Harpe Golden wrote:
>>
>> modify emacs to comply with the client-side of the spec,
>> which would be a good thing anyway.
>
> I've filed this part taken on its own as emacs bug #8641
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8641

Great thanks for all your time and investigation into this; I have to
admit that I don't fully understand it all, but I do have a much
clearer picture. Just let me know if you come up with any possible
fixes or workarounds and I'll be more than happy to test them. In the
mean time, I just made delete-word and backward-delete-word functions
and bound them to C-<delete> and C-<backspace>. Rarely did I ever
really want words thus removed put into the kill ring anyway,
especially when I used them in the minibuffer e.g. editing a file
name.

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

Re: Strange slowness when killing words interactively

[Chong Yidong]

Taylor Venable <taylor@metasyntax.net> writes:

> Just let me know if you come up with any possible fixes or workarounds
> and I'll be more than happy to test them.

I'd like to find out if implementing the client side of the clipboard
manager spec, as David suggests, will reduce the slowness.  Could you
apply this patch (with the clipboard manager enabled and all other parts
of Emacs as per default) and see if it makes any performance difference?

*** lisp/select.el	2011-04-19 13:44:55 +0000
--- lisp/select.el	2011-05-16 22:25:40 +0000
***************
*** 384,389 ****
--- 384,392 ----
  	(NAME . xselect-convert-to-name)
  	(ATOM . xselect-convert-to-atom)
  	(INTEGER . xselect-convert-to-integer)
+ 	;; From freedesktop.org Clipboard Manager spec: used to tell
+ 	;; clipboard manager that we support SAVE_TARGETS.
+ 	(SAVE_TARGETS . ignore)
  	(_EMACS_INTERNAL . xselect-convert-to-identity)))
  
  (provide 'select)

Re: Strange slowness when killing words interactively

[David De La Harpe Golden]

On 16/05/11 23:32, Chong Yidong wrote:
> Taylor Venable<taylor@metasyntax.net>  writes:
>
>> Just let me know if you come up with any possible fixes or workarounds
>> and I'll be more than happy to test them.
>
> I'd like to find out if implementing the client side of the clipboard
> manager spec, as David suggests, will reduce the slowness.

Heh, I just tried essentially that a few minutes ago ...it doesn't.

I was about to open an XFCE bug about the issue - will I go ahead and do so?

Re: Strange slowness when killing words interactively

[Chong Yidong]

David De La Harpe Golden <david@harpegolden.net> writes:

> On 16/05/11 23:32, Chong Yidong wrote:
>> Taylor Venable<taylor@metasyntax.net>  writes:
>>
>>> Just let me know if you come up with any possible fixes or
>>> workarounds and I'll be more than happy to test them.
>>
>> I'd like to find out if implementing the client side of the clipboard
>> manager spec, as David suggests, will reduce the slowness.
>
> Heh, I just tried essentially that a few minutes ago ...it doesn't.
>
> I was about to open an XFCE bug about the issue - will I go ahead and
> do so?

Yes, please.

Re: Strange slowness when killing words interactively

[David De La Harpe Golden]

On 17/05/11 18:31, Chong Yidong wrote:
> David De La Harpe Golden<david@harpegolden.net>  writes:
>> I was about to open an XFCE bug about the issue - will I go ahead and
>> do so?
>
> Yes, please.

right so. filed as XFCE bug #7633

https://bugzilla.xfce.org/show_bug.cgi?id=7633

Re: Strange slowness when killing words interactively

[David De La Harpe Golden]

On 17/05/11 18:48, David De La Harpe Golden wrote:

> right so. filed as XFCE bug #7633
>
> https://bugzilla.xfce.org/show_bug.cgi?id=7633

...and in reply at that link, Nick Schermer says that it had already 
been fixed in xfce's master branch. So, good news, problem should just 
go away when there is a new XFCE release with the changes and you 
upgrade to it.