From kde-optimize Mon Sep 11 23:23:05 2006 From: Lubos Lunak Date: Mon, 11 Sep 2006 23:23:05 +0000 To: kde-optimize Subject: Re: Desktop memory usage Message-Id: <200609120123.06021.l.lunak () suse ! cz> X-MARC-Message: https://marc.info/?l=kde-optimize&m=115801692626490 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--Boundary-00=_a/eBFVnsv/OgzLu" --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" =20

Desktop memory usage

Introduction

This 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:
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.

2. Very plain desktop

"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:

DesktopUsageDiff
KDE60.4 (57.6)29.1 (14.4)
GNOME74.8 (71.2)43.5 (28)
Xfce47.9 (52.6)16.6 (9.4)
WMaker36.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.

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.

3. Very plain desktop with 3 basic applications

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:

DesktopUsageDiffVery plain diff
KDE75.3 (67.5)44 (24.3)14.9 (9.9)
GNOME90.2 (83.0)58.9 (39.8)15.4 (11.8)
Xfce60.1 (62.8)28.8 (20.5)12.2 (10.2)
WMaker42.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.

4. Plain 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:

DesktopUsageDiffVery plain diff
KDE73.8 (68.1)42.5 (24.9)13.4 (10.5)
GNOME95.3 (90.6)64.0 (47.4)20.5 (19.4)
Xfce48.5 (52.9)17.2 (9.7)0.6 (0.3)
WMaker40.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.

=20

5. Desktop with 3 basic applications

These 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:

DesktopUsageDiff
KDE85.8 (72.3)54.5 (29.1)
GNOME110.4 (103.0)79.1 (59.8)
Xfce58.3 (61.0)27.0 (17.8)
WMaker51.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.

6. Web browser

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 + browserUsageDiff
KDE + Konqueror95.3 (83.8)9.5 (11.5)
KDE + Firefox108.0 (90.4)22.2 (18.1)
KDE + Epiphany112.5 (91.5)26.7 (19.2)
GNOME + Epiphany127.7 (114.6)17.3 (11.6)
GNOME + Firefox133.6 (118.8)23.2 (15.8)
GNOME + Konqueror136.5 (113.3)26.1 (10.3)
Xfce + Firefox80.2 (73.2)21.2 (12.2)
Xfce + Epiphany82.6 (72.4)24.3 (11.4)
Xfce + Konqueror84.4 (71.6)26.1 (10.6)
WMaker + Firefox69.9 (65.9)18.5 (6.2)
WMaker + Epiphany74.3 (65.9)22.9 (6.2)
WMaker + Konqueror80.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.)

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.

7. Office suite

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 + suiteUsageDiff
KDE + KWord100.0 (81.5)14.2 (9.2)
KDE + OOWriter166.7 (110.5)80.9 (38.2)
KDE + Abiword102.2 (85.4)16.4 (13.1)
GNOME + Abiword121.4 (117.8)11.0 (14.8)
GNOME + OOWriter196.3 (138.1)85.9 (35.1)
GNOME + KWord140.9 (115.3)30.5 (12.3)
Xfce + OOWriter142.1 (96.5)83.8 (35.5)
Xfce + Abiword77.1 (68.7)18.8 (7.7)
Xfce + KWord89.4 (72.3)31.1 (11.3)
WMaker + OOWriter124.7 (90.8)73.3 (31.3)
WMaker + Abiword64.8 (62.0)13.4 (2.3)
WMaker + KWord76.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?

8. Desktop's applications

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):

DesktopUsageDiff
KDE + KDE apps143.2 (117.7)111.9 (74.5)
GNOME + GNOME apps174.8 (149.3)143.5 (106.1)
Xfce + 3rd party apps206.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.=

Conclusion

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:

Lubos Lunak <l.lunak@kde.org> <l.lunak@suse.cz> --Boundary-00=_a/eBFVnsv/OgzLu Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kde-optimize mailing list Kde-optimize@kde.org https://mail.kde.org/mailman/listinfo/kde-optimize --Boundary-00=_a/eBFVnsv/OgzLu--