Allen S. Rout [2012.04.17 1021 -0400]:

On 04/16/2012 03:09 PM, Norbert Zeh wrote:

...

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.[...]

This matches my observations:

http://thread.gmane.org/gmane.comp.lang.haskell.xmonad/12168

...

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.

Well, actually that never happened to me. From the user's point of view, focus switching is snappy unless I increase the number of windows to an unreasonable 100+. My main issue is simply that a simple focus switch shouldn't cause more than a minor blip in my CPU usage. N.

Allen S. Rout [2012.04.17 1407 -0400]:

On 04/17/2012 01:23 PM, Norbert Zeh wrote:

...

Well, actually that never happened to me. From the user's point of view, focus switching is snappy unless I increase the number of windows to an unreasonable 100+.

..? I've currently got 26 workspaces, some of which only have one window, but many of which have 4 or more. I'm probably going to have upwards of 40 before my count really stabilizes. Do you really think that's simply "unreasonable" ?

The thought that someone at the window-manager level ought to be saying "oh, it's simply unreasonable to do more than <X>" with other than stark technical reasons... well, it raises my hackles something fierce.

The number of workspaces should have no effect on this, as I would think that invisible workspaces cause no traffic to the X server. If they do, now *that* would be something even more important to fix. So what I was referring to was the number of mapped (visible) windows. Once I get to tiling 100+ windows even on 4 screens, none of them is usable any more because it shows too little information, except maybe if I tile them to have an Expose-like preview of all my windows and then maximize each window in turn when I actually want to do some work in it. Thus, I would consider 100+ simultaneously mapped windows unreasonable. In the end, though, what I consider reasonable or not is unimportant. The point remains that a simple focus switch should not cause a major spike in CPU usage. Cheers, Norbert

On Tue, Apr 17, 2012 at 10:21, Allen S. Rout 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.) -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

On Tue, Apr 17, 2012 at 14:23, Norbert Zeh wrote:

Brandon Allbery [2012.04.17 1344 -0400]:

...

(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

Caching previous computations is a pretty necessary part of the full solution to that issue, which is why I pointed to it. -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms