Weblog entry #2 for Azerthoth
See all weblog entries made by Azerthoth.
The following are a few things I discovered about how much memory is used by the base system using the following ground rules.
1: Reboot between each test to guarantee that the system memory was completely flushed.
2: The only running program that I added would be conky. If you have looked at the snapshot of my destop, its the system monitor that is in the top right corner of the display.
Fluxbox: 38.7 meg
Openbox: 40.1 meg
KDE: 57.6 meg
Afterstep: 60.9 meg
Gnome: 77.6 meg
Admittedly Gnome running that high suprised me a bit. I had been expecting KDE to take that position. Openbox shocked me a bit as well, I had assumed that it would have been less than Fluxbox.
The next thing that was under debate (I was getting lightly flamed for in my bashing of KDE) was that konqueror was faster and had a lighter footprint than Firefox. This is true if you happen to be running KDE, because upon a bit of looking KDE precaches a few things. For the next bit of testing I only used KDE and Fluxbox, the reasoning being that while Firefox is not native to either, konqueror is native to KDE.
Fluxbox:
App %CPU %mem
konqueror 2.7% 4.9%
firefox .5% 4.5%
This isnt the whole story though, when bringing up konqueror the following extra processes fired.
klauncher 0.0% 1.5%
kded 0.0% 2.1%
kdeinit 0.0% 1.6%
kiofile 0.0% 1.6%
kiofile 0.0% 1.6%
kiofile 0.0% 1.6%
kiofile 0.0% 1.6%
dcopserver 0.0% 1.3%
KDE
firefox 0.7% 4.5%
konqueror 1.4% 4.6%
Now of course when we went to look, all those same extra apps were in place and running. The interesting thing I saw was that those same 4 kiofile processes disappeared when I shut konqueror down. However if you want here are the same processes I found in Fluxbox but this time running inside KDE, some of these of course are running when in KDE regardless (that sneaky precaching)
kiofile 0.0% 1.5%
kiofile 0.0% 1.5%
kiofile 0.0% 1.5%
kiofile 0.0 % 1.5%
kded 0.5% 3.0%
dcopserver 0.0% 0.5%
kdeinit 0.1% 1.5%
klauncher 0.0% 1.6%
Let me close this with:
A: This is not truly a fair test. Konqueror does much more than just act as a web browser.
B: All the info I pulled in the second half of the comparison was gained by the use of
ps -aux
while both firefox and konqueror were minimized in exactly the same condition that they opened up in. I didnt go to any websites or browse and files.
C: In running the same set of tests in Gnome the results were close enough to the same as the first to as to not to mention it.
D: I wont draw any conclusions for anyone, but let the numbers tell their story.
Regardless, I will still use both programs as the need arises. Firefox for webbrowsing and Konqueror for system browsing. The previous tests were run on a compaq presario R3200, 2.6.16r2 non optimized kernel, AMD+3000 32bit, and 512M ram.
If someone runs similar tests and comes up with significantly different numbers, please share them.
Comments on this Entry
B: All the info I pulled in the second half of the comparison was gained by the use of
ps -aux
Huh?
You are counting RSS, don't you?
Your test is simply flawed for exactly that reason.
It was known for long time (at least in development community) that RSS value is rather worthless and should be _not_ used to count memory usage. At least for certain programs.
Here is the reason: few programs instead of using libraries to do certain functions they rather spawn another processes to do their job. These processes usualy share libraries and *data* until that data will really change (copy-on-write). You can't reliably know given program memory usage by summing up RSS values.
Since linux-2.6.14 there is /proc/pid/smaps for exactly that reason -- to make it possible to count real memory usage. Sadly, I'm not aware of any ps-like (or top-like) tools that make use of this interface. There is Linux::Smaps perl module, but that's all.
See here for better explanation.
while both firefox and konqueror were minimized in exactly the same condition that they opened up in. I didnt go to any websites or browse and files.
Which is sad, maybe next time you should consider *using* each browser for an hour on old hardware? You may *then* notice which browser is faster and uses less memory.
D: I wont draw any conclusions for anyone, but let the numbers tell their story.
Please note however, that these numbers doesn't tell _anything_ about _real_ memory usage.
[ Parent | Reply to this comment ]
I am not saying that you are wrong, you may very well have hit the nail on the head. However, in saying that the results I came up with are meaningless without supplying metrics of your own and/or a duplicatable test procedure is basicly only supplying an opinion. Unfortunatly opinions were exactly what was being tackled here, with solid numbers.
I invite you to attach some solid numbers and a repeatable test procedure, I will readily admit defeat if it comes down to that. At this point you have only laid out an opinion based upon "what everyone knows".
Converting M$ addicts one CD at a time.
[ Parent | Reply to this comment ]
I thank you for the comment. However I have found no supporting documentation for your claims, the link you supplied is unfortunatly dead and hunting leads has supplied amazingly little information that wasnt changelogs, or code snippets for configuration.
And that's the problem I mentioned -- there is *no* reliable way to report memory usage of given program. All we have is Linux::Smaps.
Here's correct link.
I am not saying that you are wrong, you may very well have hit the nail on the head. However, in saying that the results I came up with are meaningless without supplying metrics of your own and/or a duplicatable test procedure is basicly only supplying an opinion. Unfortunatly opinions were exactly what was being tackled here, with solid numbers.
I've pointed you to Linux::Smaps (and /proc/pid/smaps)
Consider for example this comment:
About the clock applet: you should not trust an memory usage reported by the Linux kernel. In a desktop environment like Gnome, most of the memory is shared between applications and libraries. A more accurate way to evalute the memory footprint of the clock applet is to substract its SHARED memory from its RESIDENT memory. On my system (amd64) that gives 1.6MB.
Even 1.6MB is quite a lot for a simple clock.
A quick look in the memory map shows that about half of it is used by the clock applet itself (HEAP+STACK). The rest is used by the non-readonly segments (and so non-shared) of the shared libraries.Source is here. Please consider reading whole thread.
And be sure to read this thread.
Googling http://mars.theaimsgroup.com for "smaps" might reveal more iteresting threads.
I invite you to attach some solid numbers and a repeatable test procedure, I will readily admit defeat if it comes down to that. At this point you have only laid out an opinion based upon "what everyone knows".
Nope. I've said that there is no tool to properly measure given program memory usage.
BTW I've been blocked from posting anonymously on this site. Could someone tell me why? Have I offended someone? Have I been rude?
I was forced to create account to post these simple clarifactions, that isn't nice.
[ Parent | Reply to this comment ]
http://virtualthreads.blogspot.com/2006/02/understanding-memory-u sage-on-linux.html
Also you want to make sure apps aren't doing anything perculiar themselves, like maintaining their own cache, or weird memory mapping tricks.
I've no idea what it is that Thunderbird and Firefox do on my box to apparently use quite so much memory, I may have a play to try and find out. I did try and play with the memory allocation stuff in the Mozilla apps once (some, but not all allocators can do things based on environment variables).
I'm also going to have a play with Galeon and Epiphany and friends, and see how they compare.
Search also "free the fish" and "gegls from outer space" for GNONE Easter eggs. I never did figure out how efficiently or otherwise these are implemented, but I couldn't find the graphics files, so I suspect they are rotting in the code somewhere.
I think there is a lot of bloat in there somewhere, but one needs to be realistic about goals. Does it make sense to spend a lot of effort making small desktops when memory is relatively cheap. I think it is worth some effort, as it prolongs the life of old hardware, my desktop at work may be old and clunky, but really it should run web browsers a tad faster than it does. Indeed I think there is little excuse for basic software like that not being instantaneous for basic actions, like requesting a new tab in the browser. The worst it does is KDE opening a new tab in Firefox, I suspect it is downloading the page at least twice, but I haven't proved that yet.
[ Parent | Reply to this comment ]
Sorry for the delay in getting back to this. I ran into an issue with the 2.6.17-2 kernel and its supposed built in support for bcm43xx chipsets. More on that battle later though, I'm still writting out the problem and the solution I used. That article once done should stir the GPL religious action group into a fine lather, I'm almost looking forward to the comments (flames) that one will generate.
Converting M$ addicts one CD at a time.
[ Parent | Reply to this comment ]