Re: [xmonad] Delays in focus update...

6 Feb 2012

      Norbert Zeh [2012.02.06 1924 -0400]:
...
Brandon Allbery [2012.02.06 1744 -0500]:
...
On Mon, Feb 6, 2012 at 17:31, Norbert Zeh  wrote:
Allen S. Rout [2012.02.06 1453 -0500]:
    > But I've noticed a certain lack of responsiveness when I make
    > sweeping motions with the mouse, and I've now done a bit of an
    > experiment  that seems to narrow it down.
I am not entirely certain what inside the decoration module would create
    such
    massive delays - the CPU usage on one of my cores goes up to 50% when I'm
    in the
    endless loop.  I'm not too keen to dig into it because this module is a
    monster,
    but it may simply be necessary.
Two things that come to mind are that
(a) decoration windows are, somewhat uselessly, part of the StackSet and must
be traversed whenever the StackSet is searched for the newly focused window;
I had one brief look at the decoration code and decided that I do not want to
understand it.  Maybe it's time to reevaluate this decision.  Making these
windows part of the stackset is certainly completely wrong.  It's equivalent to
having the frame X window of a reparenting window manager show up in the window
list.  However, adding them to the stack should only cause a factor 2 slowdown,
while the slowdown I experience is more a factor 10+.
...
(b) Decoration registers interest in all events on decoration windows,
specifically including mouse events IIRC, and (usually pointlessly) invokes a
(usually stub) handler on such events.
This sounds more like the real culprit.
...
BTW, the tabs module really needs to be rewritten not to use Decoration; not
only is Decoration inefficient, as above, but tabs are actually a rather poor
fit for Decoration because most of the Decoration code assumes decoration
windows take up space near the real window, and odd things happen with respect
to space allocation when they are instead located somewhere else.  (I have
local hacks around that which fix most of the odd things with respect to
figuring out the available workspace area, but not all of them; and it still
leaves the performance issues.)
I am actually using decoration to add "title bars" above my windows.  So, while
separating the decoration and tab modules may be a good idea due to the reasons
you cite, it wouldn't help fix the performance issues for people (like myself)
who actually do use decoration as it was meant to be used.
Bottom line: someone will have to look at that decoration code, maybe I when I
find the time, but I'd be happy if someone else beat me to it ;)
Alright.  I at least *started* to look and found two sources of inefficiency,
one which I thought would be major but which is actually insignificant in
comparison to the other one, the other one really troublesome:

1) The decoration state associating windows with their decorations is a list.  I
need to check how these are used, but I remember seeing a lookup in this list
later on.  By storing this in a Map instead, we could cut the time per operation
from linear to logarithmic.

2) At least the default implementation of pureDecoration, which is used at least
by the simple decorations based on the Decoration class, checks for every window
to be decorated whether it is in the stack.  This takes *quadratic* time.  Now
I'm no longer surprised at the poor performance because every layout update on a
workspace with 8 windows now incurs a cost equivalent to walking through a stack
with 64 windows in it!  By doing these lookups more cleverly, we can at least
reduce the time to a more reasonable n log n.

Cheers,
Norbert