[xmonad] XMonad Efficiency

[Norbert Zeh]

Hi folks,

I must admit that I for now gave up on trying to make the decoration module more
efficient.  I tried two of the three ideas I had, and they didn't work well at
all.  My third idea (turning most of the lists in the decoration module into
binary trees) is likely to work well, but for now I don't have time to implement
it, particularly because it's not one of my main issues I would like to see
addressed in xmonad.

Related to the above, however, I noticed that even without decoration, fast
focus switches drive my CPU usage up, much more so than in other non-tiling
window managers.  Running top gave me a surprising insight: it's not xmonad but
the X server that consumes that many cpu cycles when focus switching.  Here's my
theory of the source of the issue: every focus change triggers the recomputation
of the layout (as it should because some layouts rearrange windows in response
to focus changes), and every recomputation of the layout updates the geometry of
every window currently visible - that's a lot of work on the X server's side for
a simple focus change.

(1) Can anybody who is more familiar with the inner workings of xmonad core
confirm that this is indeed what's going on?

(2) A fairly simple fix for the above would be to cache the geometries of
visible windows and tell the X server to update a window only if its geometry
has in fact changed.  Does anyone on the list have a feel for how hard it would
be to add such a caching mechanism to xmonad core?  Would it break anything?

At this point, I'm simply pondering what can be done about it, as one of the
reason's I'm using xmonad is that I want a lightweight desktop environment.
(When fast focus changes drive one of my cores to 50%, that's hardly
lightweight.)  It'll be a while before I would get around to trying to implement
the above.

Cheers,
Norbert

-- 

()  ascii ribbon campaign  -  against html e-mail
/\  www.asciiribbon.org    -  against proprietary attachments