[Xmonad] xmobar-0.4 - the xmonad status bar - released!

Andrea Rossato mailing_list at istitutocolli.org
Thu Jul 5 13:12:53 EDT 2007

On Thu, Jul 05, 2007 at 06:57:27PM +0200, Robert Manea wrote:
> True for the virtual memory size. Still, the question remains why does
> xmonad which is obviuosly also linked to "everything needed to run a
> haskell binary" _not_ use equally much memory? 
> The answer might be: because xmobar uses some really huge libraries that
> are not being used by/shared with any other haskell prog i use. So if I
> go one step further i could conclude that I'm spending a lot of precious
> memory for only a single application.

I totally agree with you.

> * A haskell programm with a fair bit higher complexity than xmobar needs
>   way less memory or said in other words does not need that many huge
>   supporting librarieѕ as xmobar.

xmobar is doing far more complex things than xmonad is doing.

just read the code. Xmonad does nothing but keeping track of the
windows you open, in a very well design data structure.

xmobar parses, forks threads, opens, closes files in very small
amounts of time, writes variables shared by threads, and does a lot of
very highly difficult operations.

Look, I'm far from saying that xmobar is a nice piece of code (I don't
care that much, about xmobar, or just about my coding capacity). But
it does a lot of very complicated things. Probably in the most
inefficiently conceivable way. Still a lot of stuff. Go read it!

> * A program (dzen) with a somewhat comparable feature set needs way less
>   memory. 

yes, and it requires learning a very complicated programming language, with manual
memory allocation and uncontrolled side effects.
Memory is cheap, bro...;-)

> Please do not take this as any kind of offense, i just wanted to point
> out the obvious :):

we are just sharing code and opinions. this is just great, isn't it?



More information about the Xmonad mailing list