[Top][All Lists]

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

Re: Strange slowness when killing words interactively

From: David De La Harpe Golden
Subject: Re: Strange slowness when killing words interactively
Date: Mon, 09 May 2011 02:18:00 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110402 Icedove/3.1.9

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: emacs_xfce_clipboard_1.log
Description: Text Data

Attachment: emacs_xfce_primary_1.log
Description: Text Data

Attachment: emacs_gnome_clipboard_1.log
Description: Text Data

Attachment: emacs_gnome_primary_1.log
Description: Text Data

reply via email to

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