[xmonad] Delays in focus update...

[Norbert Zeh]

Norbert Zeh [2012.02.06 1924 -0400]:
> Brandon Allbery [2012.02.06 1744 -0500]:
> > On Mon, Feb 6, 2012 at 17:31, Norbert Zeh <nzeh at cs.dal.ca> 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