--Boundary-00=_a/eBFVnsv/OgzLu Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Updated version attached. -- Lubos Lunak KDE developer -------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: l.lunak@suse.cz , l.lunak@kde.org Lihovarska 1060/12 tel: +420 284 028 972 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http//www.suse.cz --Boundary-00=_a/eBFVnsv/OgzLu Content-Type: text/html; charset="utf-8"; name="memory.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="memory.html"
=20This was actually supposed to be a follow-up to my tests of startup performance of various desktop environments, pr= imarily KDE of course :). In fact I even did most of the benchmarks some ti= me after the startup ones, but, alas, I'm much better at writing things tha= t computers are supposed to read than at writing things that people will re= ad :-/ (some volunteer to write good user documentation for KWin's window s= pecific settings, BTW ;) ?) I even meant to make a somewhat more extensive = analysis of the numbers, but having never found time to write that, I decid= ed I should publish at least a shorter variant with all the numbers and som= e conclusions. You can do your own analyses of the numbers if you will.
These memory benchmarks are meant to measure various cases of desktop confi= guration and compare KDE to some other desktop environments. Specifically, = I compared against Xfce 4.2.2 (as shipped with SUSE Linux 10.0) as the so-c= alled lightweight desktop, WindowMaker 0.92.0 as a plain window manager and= GNOME. GNOME, built using GARNOME, was originally version 2.12.2, later re= doing it with 2.14.0 (without actually measuring noticeable difference in t= hese specific cases, despite 2.14 release notes claiming performance improv= ements). As I no longer have the same setup I cannot redo it with the very = recent 2.16 unfortunately. Simply consider this to be a bit old. The others= are for comparison anyway :). KDE itself was KDE 3.5.2 with my performance= patches, all of which are already upstream by now.
The tool used to measure memory usage was Exmap - the only tool for measuring memory usage that I'v= e ever found to be actually useful (I think I've already blogged about it ;) ). Its so-called e= ffective memory usage numbers try to account for things like dividing share= d libraries among all the processes using them, unlike tools like top that just report the numbers they find in /proc and nobody really = knows how to interpret them. In other words, if you use things like top<= /i> or free for precise measuring of memory usage, you're crazy. Nev= ertheless, for the crazy ones, I used also free alongside with Exmap= , just for the fun of it, numbers from free will follow in parenthes= es. They should not be considered to be useful though.
The actual measuring was roughly like this: I had SUSE Linux 10.0 running i=
n runlevel 3, i.e. without any X started automatically. I started X manuall=
y myself, with only xterm running. Then I measured total system memory usag=
e (total effective memory in Exmap, -/+ buffers/cache in free=
, there was never any swap usage). Launched KDE/GNOME/Xfce/WindowMaker in a=
particular tested setup and measured total system memory usage again, the =
same way. The difference of course was the memory used by the various envir=
onment itself. So, let's see the actual numbers:
1. Plain X
This number is definitely worth mentioning as well. The case when no deskto= p is running at all, only system daemons, X and xterm. And the number is:= p>
31.3 (43.2) |
Yes, more than 30M in use already, according to Exmap (and more than 40M ac= cording to free, but I myself trust the Exmap number more). Effectiv= e memory usage from Exmap for apps shows that 12.3M is taken by X, running = at 1024x768x16, 3.0M by HAL daemon (out of which 2M is private data, don't = ask me why) and xterm takes 2.2M. Since this is SUSE Linux 10.0, there isn'= t any ZMD or anything like that. Some of these things already running use c= ode that is also reused by desktops, for example xterm uses some X11 librar= ies, so all the numbers are offset by this value, although it should be rel= atively small and is the same for all desktops. Although HAL daemon uses so= me GNOME libraries, due to using GARNOME these are different than the ones = used by GNOME in all these benchmarks.
"Very plain" means minimal functionality. In KDE's case there there was onl= y the basic desktop and very basic panel applets like the taskbar, pager an= d clock. Similarly with other desktops. The desktops were fully functional = though, without any "cheating" like I did during the last Akademy talk. And= the numbers are:
Desktop | Usage | Diff |
KDE | 60.4 (57.6) | 29.1 (14.4) |
GNOME | 74.8 (71.2) | 43.5 (28) |
Xfce | 47.9 (52.6) | 16.6 (9.4) |
WMaker | 36.9 (47.0) | 5.6 (3.8) |
To explain the numbers once more: "Usage" is total memory usage when runnin= g the specific desktop in the given setup. The first number is from Exmap, = the one in parentheses is from free. "Diff" is a difference to some = base state, in this case to the plain X state from se= ction 1. I.e. it's the memory increase caused by running the desktop.= p>
I have already said the free numbers are these mostly only for the f= un of it, haven't I? These numbers seem to differ a lot between Exmap and <= i>free. One explanation for I have is that they interpret differently w= hat used memory actually is. Consider files that are mmapped for read-only = access, such as KSycoca or GNOME's icon caches. Exmap counts them as used m= emory (the parts that are really in memory), while free counts them = as part of cached, i.e. not considering them to be a really used mem= ory. I consider the free approach to be wrong. In order to use KSyco= ca, it has to be in memory, of course, in order to read the data from it. S= o it really takes up some memory. Because it's a read-only mapping, this me= mory can be actually discarded whenever needed, so in a way it could be con= sidered the memory is not really taken, but those data need to be loaded in= to memory again when they're needed and this memory is necessary for loadin= g the contents from the file. Besides, repeated loading from disk would be = of course horribly slow. If you think this is wrong thinking, just use the = same logic with libraries. They are (mostly) read-only mappings of the bina= ries and therefore act similarly. And they indeed need to be in memory in o= rder for applications using them to work and use them. KDE's base libraries= are about 15M and if you'd prefer the free thinking approach, you'd= have to subtract this number from KDE's memory usage. Yet of course many p= eople complain about the fact that using any KDE application means loading = KDE's libraries into memory.
As for the actual results, well, too bad. In fact I had been hoping, somewh= at naively indeed, that such very stripped KDE would match Xfce like it did with the startup ti= me. But the size of KDE's libraries is hard to beat and with such stripped = desktop there is not that much that'd take advantage of it. GNOME's huge nu= mber seems to be caused by running way too many processes - even panel appl= ets are separate processes. This will have even worse impact later.
Desktops alone are of course not very useful. One needs to run some applica= tions to actually make use of the computer. So in addition to the very plai= n desktop there were 3 applications running: A terminal, a text editor and = a file browser. In KDE's case the choice is obvious, they are Konsole, KWri= te and Konqueror. In GNOME's case they are GNOME Terminal, Gedit and Nautil= us. The terminal button in Xfce launches XTerm, editor for Xfce is Mousepad= and for file management there was XFFM. In the WindowMaker case the choice= was the hardest - it is just a window manager and it doesn't come with any= accompanying applications at all, besides applets. Eventually I decided on= running 3 times Xterm: One as a terminal, one with vi as an editor = (sorry Emacs users)and one with just shell as the "file manager" - that see= ms to match what the Window Maker users I know run :). Numbers:
Desktop | Usage | Diff | Very plain diff |
KDE | 75.3 (67.5) | 44 (24.3) | 14.9 (9.9) |
GNOME | 90.2 (83.0) | 58.9 (39.8) | 15.4 (11.8) |
Xfce | 60.1 (62.8) | 28.8 (20.5) | 12.2 (10.2) |
WMaker | 42.2 (51.0) | 10.9 (7.8) | 5.3 (4.0) |
("Diff" is a difference to plain X, "Very plain d= iff" is a difference to the very plain desktop.)<= /p>
Not that big differences really, although generally 4-5 M per application i= s not that little (note though that this includes also the binaries). Windo= wMaker case is somewhat special in reusing the same application three times= and also generally not being really desktop.
However, people usually don't use very plain desktops. Besides the basic pa= nel applets they often run additional ones, for controlling sound volume, s= howing CPU usage, showing time, switching keyboard layouts and so on. So in= this case the very plain desktop additionally runs some of these applets, = specifically, in KDE's case, Clock, Klipper, KTimeMon, KMixApplet, KGet, KX= KB, KNotes and the systray applet. I tried to make this selection in order = to match the reality, but had to adjust it in order to have similar sets fo= r other desktops (although even now it doesn't 100% match, for example I co= uldn't find any KGet equivalent for Xfce). The numbers are:
Desktop | Usage | Diff | Very plain diff |
KDE | 73.8 (68.1) | 42.5 (24.9) | 13.4 (10.5) |
GNOME | 95.3 (90.6) | 64.0 (47.4) | 20.5 (19.4) |
Xfce | 48.5 (52.9) | 17.2 (9.7) | 0.6 (0.3) |
WMaker | 40.9 (49.7) | 9.6 (6.5) | 4.0 (2.7) |
(Again, "Diff" is a difference to plain X, "Very = plain diff" is a difference to the very plain desktop= . In this case the 3 applications are not run= ning.)
More than 10M for 8 applets isn't very impressive. The number could have be= en much worse or better depending on the exact sets of applets though. Some= of them were real Kicker applets that are loaded into the Kicker process (= Clock, Klipper, KTimeMon, KMixApplet, Systray) and as such are lightweight,= others are full-blown KDE processes (and KNotes even drags in KDEPIM libra= ries). GNOME's bad numbers even more show that separate processes can have = high costs. The Xfce value shines though. All panel applets are loaded into= the Xfce panel process and are very lightweight, beating even Window Maker= in this specific test (although only in the difference and not in the tota= l value). Window Maker applets are also separate processes, even if quite l= ightweight.
Just in case you wonder, the fact that many processes are rather heavy can = be easily seen in the process list in Exmap. But I had known this even befo= re doing this test.
Conclusion for KDE: We should generally try to avoid unnecessary pro= cesses. There should be no need to have a full KDE application for just swi= tching keyboard layouts and showing an icon. Unlike Kicker applets the syst= ray even encourages this, with the practice of every systray icon being a s= eparate applet. Even worse, most of systray icons are not even needed 99% o= f the time - why should KGet be there all the time when it mostly only show= s an inactive icon? I've already talked to Aaron about this and the plan is= to have special support for such cases that unnecessarily increase memory = usage and startup time.
=20These numbers are the sum of the two above cases. They are not necessarily = real sums of the two differences though, as some code might be reused:
Desktop | Usage | Diff |
KDE | 85.8 (72.3) | 54.5 (29.1) |
GNOME | 110.4 (103.0) | 79.1 (59.8) |
Xfce | 58.3 (61.0) | 27.0 (17.8) |
WMaker | 51.4 (59.7) | 20.1 (16.5) |
("Diff" is difference to plain X.)
KDE here could do somewhat better with applets handled differently. There p= robably can't be done much with the big increase caused by KDE libraries, t= here aren't that many applications using them in this case and things like = ease of development unfortunately don't show in this test. Thanks to the us= e of kdeinit these numbers are still noticeably lower than they woul= d have been without it (and since prelink doesn't change that much a= bout it, people concerned about memory usage and using prelink shoul= d try running KDE without $KDE_IS_PRELINKED set).
Xfce in these basic tests performs excellently, almost keeping up with Wind= ow Maker while actually being a desktop and not just a window manager with = few applet apps and several terminals. Its integrated applets and basic app= lications give it an advantage here. The fact that only basic applications = come with Xfce and for more advances ones like web browsers one has to go t= o look elsewhere doesn't show yet.
A very common usage case :). In addition a web browser is launched, showing= a random WWW site, specifically http://dot.kde.org ;). Browsers used were = KDE's Konqueror, GNOME's Epiphany and Firefox 1.0.6. To show how applicatio= ns work when not in their native desktop I measured all of them in all desk= tops:
Desktop + browser | Usage | Diff |
KDE + Konqueror | 95.3 (83.8) | 9.5 (11.5) |
KDE + Firefox | 108.0 (90.4) | 22.2 (18.1) |
KDE + Epiphany | 112.5 (91.5) | 26.7 (19.2) |
GNOME + Epiphany | 127.7 (114.6) | 17.3 (11.6) |
GNOME + Firefox | 133.6 (118.8) | 23.2 (15.8) |
GNOME + Konqueror | 136.5 (113.3) | 26.1 (10.3) |
Xfce + Firefox | 80.2 (73.2) | 21.2 (12.2) |
Xfce + Epiphany | 82.6 (72.4) | 24.3 (11.4) |
Xfce + Konqueror | 84.4 (71.6) | 26.1 (10.6) |
WMaker + Firefox | 69.9 (65.9) | 18.5 (6.2) |
WMaker + Epiphany | 74.3 (65.9) | 22.9 (6.2) |
WMaker + Konqueror | 80.2 (65.1) | 28.8 (5.4) |
("Diff" is difference to desktop with 3 basic applica= tions, i.e. it is the memory increase caused by running the browser.)= p>
Here some numbers that one would expect to be the same (e.g. Firefox in var= ious desktops) vary a bit, partially due to various reuse of libraries, par= tially probably due to "noise". Although the numbers are stated with precis= ion to one decimal place, you're crazy if you don't round them up a bit mor= e - this is benchmarking, not mathematics. The only number that seems to be= somewhat strange is Firefox in Window Maker where the change is smaller th= an in other desktops. It may be a mistake on my side (which I can't check a= nymore) or perhaps some desktop-specific support in Firefox that doesn't ge= t activated in Window Maker.
Konqueror in this case actually happens to cheat a bit, since the basic Kon= queror shell is already running in another instance as a file manager from = the basic setup. The basic setup usage without Konqueror running would have= been 84.4, so if adjusting the numbers because of this the numbers here fo= r the "KDE + Konqueror" case should be 1.4 higher, i.e. 96.7 usage and 10.9= diff. Its reuse of KDE technologies and the KHTML engine still make it a c= lear winner that's not even matched by use of Epiphany in GNOME. And, just = in case that thought crosses anybody's mind, I of course made sure there we= re no preloaded Konqueror instances.
Interestingly enough using Epiphany in KDE needs more memory than Firefox. = The same effect like with loading KDE libraries shows here, Epiphany appare= ntly uses many GNOME libraries. It's also worth noting that Konqueror's low= memory usage even manages to mostly compensate for the loading of KDE libr= aries.
This is very similar to the web browser case, this time with KWord from KOf= fice, Writer from OpenOffice.org and Abiword, all of them showing a simple = document.
Desktop + suite | Usage | Diff |
KDE + KWord | 100.0 (81.5) | 14.2 (9.2) |
KDE + OOWriter | 166.7 (110.5) | 80.9 (38.2) |
KDE + Abiword | 102.2 (85.4) | 16.4 (13.1) |
GNOME + Abiword | 121.4 (117.8) | 11.0 (14.8) |
GNOME + OOWriter | 196.3 (138.1) | 85.9 (35.1) |
GNOME + KWord | 140.9 (115.3) | 30.5 (12.3) |
Xfce + OOWriter | 142.1 (96.5) | 83.8 (35.5) |
Xfce + Abiword | 77.1 (68.7) | 18.8 (7.7) |
Xfce + KWord | 89.4 (72.3) | 31.1 (11.3) |
WMaker + OOWriter | 124.7 (90.8) | 73.3 (31.3) |
WMaker + Abiword | 64.8 (62.0) | 13.4 (2.3) |
WMaker + KWord | 76.7 (66.0) | 25.3 (6.3) |
("Diff" is difference to desktop with 3 basic applica= tions, i.e. it is the memory increase caused by running the office suit= e.)
OpenOffice used support for both KDE and GNOME, so the numbers vary in diff= erent desktops. I originally wanted to embed a table from the matching spre= adsheet counterpart, but I didn't find out how to embed a table from Gnumer= ic into Abiword, so I dropped that part. I don't know if it's actually even= possible, but I'd expect that to increase the Abiword number by Gnumeric's= about 8M because of Bonobo's out-of-process component embedding.
Numbers show that applications running in their home desktop have the small= est memory increase, as they reuse the desktop's resources. This however st= ill doesn't completely compensate for the overhead of the libraries, althou= gh there are of course differences in functionality, so no good comparison = can be made. Similarly the comparison to OpenOffice.org is not completely f= air because although other office suites provide similar functionality to i= t they don't provide as extensive set of features as OpenOffice.org .
By the way, do you remember the complains about Linux desktop being bloated, because a 128M laptop = can brought down to its knees by using KDE and running OpenOffice.org? What= do these numbers tell about it?
This one admitedly may look a lot like I'm trying to cheat. In this case KD= E running KDE applications, GNOME running GNOME applications and Xfce runni= ng generic applications will be compared. Xfce will be running generic appl= ications simply because it doesn't have any comparable on its own - no web = browser, no office suite, no mail client. In KDE's case these are going to = be Konqueror, KWord and Kontact, in GNOME's case Epiphany, Abiword and Evol= ution and Xfce will be accompanied by the most known independent applicatio= ns, that is Firefox as a web browser, OpenOffice.org as office suite and Th= underbird a mail client.
And that's where the problem is. As shown above, OpenOffice.org can "outper= form" pretty much everything else in these tests. However I don't have many= choices if I want to rule out office suites that use either KDE or GNOME l= ibraries in order to show my point. Let's first see the numbers (the diffs = are to the state when no desktop is running at all):
Desktop | Usage | Diff |
KDE + KDE apps | 143.2 (117.7) | 111.9 (74.5) |
GNOME + GNOME apps | 174.8 (149.3) | 143.5 (106.1) |
Xfce + 3rd party apps | 206.8 (135.7) | 175.5 (92.5) |
("Diff" is difference to plain X, i.e. it is the = memory increase caused by running the desktop and all the applications.)
Now I guess it's obvious why this test is a bit strange. Xfce, doing really= well in the first half, is suddenly by far the worst one. However, even af= ter adjusting, it's not going to win. The difference between KDE and Xfce h= ere is slightly more than 60M. The big effect of OpenOffice.org would have = to be compensated by this value to make Xfce match KDE in this case. That w= ould however mean OpenOffice.org almost reaching resource usage of KOffice,= which seems very unlikely, no matter how you look at it - 3rd party app us= ing its own toolkit and everything simply shouldn't be able to be as lightw= eight as KOffice which heavily reuses parts of KDE. So let's say that the X= fce value shouldn't be less than 150M - that still makes Xfce lose in the e= nd. The same thing that handicaped KDE in the beginning by causing big init= ial usage eventually lead to lightweight applications that compensated for = it.
If you still don't quite like this test, simply consider it as another reas= on for the existence of KDE. KDE here is the integrated solution using one = framework. Xfce here ended up demonstrating the state of pretty much everyb= ody rolling their own solution. Showing this was the point of this test.
GNOME's poor results here seem to be mainly result of having many expensive= processes (out-of-process applets and so on). I vaguely remember hearing s= omething about the possibility of running GNOME applets in-process, so GNOM= E developers should seriously consider doing this. However, even when ignor= ing this, GNOME still falls even more behind KDE in this last test. Epiphan= y is more demanding than Konqueror, Abiword is slightly more lightweight th= an KWord (although using components would most probably turn it around in f= avour of KOffice) and after summing up all the numbers it seems that Evolut= ion is also more demanding than Kontact.
Conclusion for KDE: When comparing applications, KDE ones often win.= In more complicated cases like this KDE applications even more than compen= sate for all the KDE libraries they use and outperform pretty much all comp= etition there is. So, whenever somebody tells us we're lame developers or t= hat C++ is much worse language than C, we know it's nonsense. And, as far a= s the Window Maker case is concerned, I don't consider that to be competiti= on. That's a different league with different users and different use cases.=
Ok, that's it. I tried quite hard to get these numbers and make sure they'r= e usable. I however cannot rule any possible mistake and I'm obviously bias= ed, so while I tried to be fair, I probably quite wasn't (however, since I = myself was curious about the results, what would be the point of cheating?)= =2E So, in case you don't believe me or these numbers, you're free to redo = this yourself, as long as you do your benchmarks somewhat correctly (it's r= eally simple to do them incorrectly, trust me). In fact, since this is actu= ally several months old, it would be nice if somebody tried with GNOME 2.16= and saved me the work.
The things we should learn from this: