[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?

ciao

Andrea


More information about the Xmonad mailing list