Tabbed Layout doesn't scale as well as it could

[GoogleCodeExporter]

Using Tabbed with a lot of windows makes it quite slow. There seems to be
non-linear work that really kills xmonad after exceeding 60 windows in a
single Tabbed Layout.

I tried with xmonad-contrib-darcs (checkout yesterday)

Here is my quite useless profiling http://clemens.endorphin.org/xmonad.prof
-- I started with a Tabbed session and starting opening xterms until the
whole thing got real slow. It's quite likely to be related to the excess
memory chewing (8gb after 37seconds).

If anyone has hints how profile xmonad-contrib better please let me know (I
got -auto-all on X11 and XMC thanks to dons' recent patch). xmonad 0.5 has
scaled a bit better, so I guess this complexity is due to some "recent"
change. 0.6 is also ok, but still it seemed a bit slower (sorry for the
vague terms, but without profiling it's hard to tell). With 0.7 there is
definitely a problem

Original issue reported on code.google.com by cle...@gmail.com on 14 Apr 2008 at 6:19

[GoogleCodeExporter]

I've reproduced the lack of profiling info -- I think its to do with the funky 
mixed
executable/libraries. (It used to work with single, static xmonad).

Original comment by don...@gmail.com on 16 Apr 2008 at 5:56

• Changed state: Accepted

[GoogleCodeExporter]

sjanssen and I looked into this last week.

Laying out the tabs appears to be O(n^2), so opening n windows becomes O(n^3).

Further, the text size calculations are O(w^2) (w the longest name) and do 
expensive
font-metric calculations.

sjanssen and I agree that those runtimes should be possible as O(n) and O(w), 
and
using a fixed-width font should remove the many font-metrics calls too.

Unfortunately, these changes are in the "rewrite" category, not the "tweak" one.

Original comment by Braden.S...@gmail.com on 16 Apr 2008 at 6:10

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

> I don't know if they are meaningful, this is why I'm posting them
> here. If they indeed are, then they are also a bit puzzling.

They are far from being puzzling if you just think a bit about them...
and indeed after thinking a bit about them I found the problem. And
the solution.

Please give the attached patch a try. You'll see that by adding a bit
of complexity to our decoration algorithm we can actually fix the
bug... oh yes, there was a bug.

Old style debugging.

ps: I see that the xmonad developers keep deleting my comments - probably this 
patch
will be shortly removed too. I don't know if they think of doing something good 
to
their users, and to their project. Anyhow, this sort of stupid behavior (it is 
called
censorship here) should give you a hint about the level of trust you should 
accord to
the window manager you are running.

Original comment by andrea.rossato@gmail.com on 1 May 2008 at 6:40

Attachments:

• 179_fix.dpatch

[GoogleCodeExporter]

Thank you andrea. Your patch practically fixed the problem for me. There still 
seems
to be an issue that makes this non-linear, but at least xmonad recovers now 
from the
shocking event that firefox-session-resume throws 50 windows at it at once (it 
takes
about 5-6 seconds to get back to normal even on my old box).

With respect to the censoring issue, I first assumed an error as I never though 
your
comment was intentionally censored. But yes it was.

For the innocent bystander, here is the original comment of andrea
http://article.gmane.org/gmane.comp.lang.haskell.xmonad/5337

Yes, there is some flame bait in this post (first paragraph). But the 
signal/noise
ratio is definitely OK, especially as andrea is the first that seriously had a 
look
at the problem. To me, the taunting remarks in the first paragraph are no
justification for censoring this comment. 

Remember, this is the free software world. In theory, we don't censor. In 
practice we
just censor much later than the rest.

Original comment by cle...@gmail.com on 1 May 2008 at 7:57

[GoogleCodeExporter]

Yes, this patch seems to help the situation greatly, thanks.  Tabbed still seems
slightly sluggish compared to other layouts, but it is certainly usable now.  
As such
I'm changing the description of the bug and leaving it open if someone wants to
address any other outstanding performance issues.

Regarding comment deletion: this bug tracker is intended only for constructive
discussion of issues with xmonad.  Andrea, the problem with your comment (and 
some
other comments in the past) is that you mix constructive contributions with 
flamebait
and emotional judgements.  Feel free to continue using this bug tracker as long 
as
you stick to concrete problems and solutions for xmonad, and leave the 
editorializing
out.

That is all I'd like to say here, any other discussion on this issue should go 
to Don
and I directly or the mailing list, as the bug tracker isn't really the proper 
place.

Original comment by SpencerJ...@gmail.com on 1 May 2008 at 8:26

• Changed title: Tabbed Layout doesn't scale as well as it could
• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I've used xmonad 0.4.1 with zwgc (zephyr windowgram client) with a fairly 
active zephyr subscription; it handled 
several hundred windowgrams with very little slowdown.  If there is a core 
performance issue then it was 
introduced more recently than that.

Now that I have a working ghc 6.8.2 on that platform I may be able to find time 
to update xmonad and stress-
test it with zwgc again.

Original comment by allber...@gmail.com on 2 May 2008 at 9:56