Re: Strange slowness when killing words interactively

[David De La Harpe Golden]

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

emacs_xfce_clipboard_1.log
Description: Text Data

emacs_xfce_primary_1.log
Description: Text Data

emacs_gnome_clipboard_1.log
Description: Text Data

emacs_gnome_primary_1.log
Description: Text Data