[xmonad] XMonad Efficiency
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
> (When fast focus changes drive one of my cores to 50%, that's hardly
> 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