[xmonad] XMonad Efficiency

Norbert Zeh nzeh at cs.dal.ca
Tue Apr 17 20:23:06 CEST 2012

Brandon Allbery [2012.04.17 1344 -0400]:
> On Tue, Apr 17, 2012 at 10:21, Allen S. Rout <asr at ufl.edu> wrote:
>     On 04/16/2012 03:09 PM, Norbert Zeh wrote:
>         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.)
>     Wait till you make a quick traverse, start typing, and find bits of your
>     input scattered among several terminals, including a root shell.
> Not saying xmonad's behavior is acceptable, but... I see this on OS X somewhat
> regularly (abusing a MacBook Air as if it were a high end desktop).
> (I am starting to think that http://code.google.com/p/xmonad/issues/detail?id=
> 494 is a priority.)

Well, they are somewhat related, but I think the issue I'm talking about here
has a much more straightforward fix than trying to generate pure approximations
of layouts that can generate their exact answer only impurely.

My idea was to keep a Map that associates a rectangle with each window ID
(actually a list + offline sorting is enough and may be faster).  After
calculating the layout, we tell the X server to reconfigure a window only if it
wasn't present the last time we refreshed the screen or its physical rectangle
has changed.  This creates a bit of overhead inside xmonad but should reduce the
traffic to the X server substantially, at least for focus updates.  It remains
to be seen whether this shifts the 50% CPU usage from X into xmonad or whether
the total is actually reduced.


More information about the xmonad mailing list