--Boundary-00=_GaBBFhGegglr771 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, I finally found some time to put together something that I had measured already quite a while ago. And I think the results are interesting. But before I post this somewhere publically I'd appreciate if somebody could at least quickly check it. I'd hate to see this trashed by people just because of some silly stupid mistake that I've managed to overlook. It still needs some final polishing but otherwise I right now consider it complete, so in case you see something wrong, missing or not clear with it, please tell me. Thanks -- 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=_GaBBFhGegglr771 Content-Type: text/plain; charset="us-ascii"; name="memory.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="memory.txt" This was actually supposed to be a follow-up to my tests of startup perform= ance of various desktop environments [http://www.kdedevelopers.org/node/166= 3 http://www.kdedevelopers.org/node/1664], primarily KDE of course :). In f= act I even did most of the benchmarks some time after the startup ones, but= , alas, I'm much better at writing things that computers are supposed to re= ad than at writing things that people will read :-/ (some volunteer to writ= e good user documentation for KWin's window specific settings, BTW ;) ?) I = even meant to make a somewhat more extensive analysis of the numbers, but h= aving never found time to write that, I decided I should publish at least a= shorter variant with all the numbers and some 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 measuring noticeable difference in these speci= fic cases (despite 2.14 release notes claiming performance improvements). A= s I no longer have the same setup I cannot redo it with the very recent 2.1= 6 unfortunately. Simply consider this to be a bit old. The others are for c= omparison anyway :). KDE itself was KDE3.5.x with my performance patches, a= ll of which are already upstream by now. The tool used to measure memory usage was Exmap [http://www.berthels.co.uk/= exmap/] - the only tool for measuring memory usage that I've ever found to = be actually useful (I think I've already blogged about it ;) [http://www.k= dedevelopers.org/node/1567]). Its so-called effective memory usage numbers = try to account for things like dividing shared libraries among all the proc= esses 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 word= s, if you use things like "top" or "free" for precise measuring of memory u= sage, you're crazy. Nevertheless, for the crazy ones, I used also "free" al= ongside with Exmap, just for the fun of it, numbers from "free" will follow= in parentheses. While the numbers from Exmap were stable when repeating th= e same benchmark, numbers from "free" vary slightly and had to be adjusted = to compensate for this. 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 (XXX) in Exmap, -/+ buffers/cache in "free", ther= e was never any swap usage). Launched KDE/GNOME/Xfce/WindowMaker in a parti= cular tested setup and measured total system memory usage again, the same w= ay. The difference of course was the memory used by the various environment= itself. So, let's see the actual numbers: 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). Effective mem= ory usage from Exmap for apps shows that 12.3M is taken by X, running at 10= 24x768x16, 3.0M by HAL daemon (out of which 2M is private data, don't ask m= e 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 code t= hat is also reused by desktops, for example xterm uses some X11 libraries, = so all the numbers are offset by this value, although it should be relative= ly small and is the same for all desktops. Although HAL daemon uses some GN= OME libraries, due to using GARNOME these are different than the ones used = by GNOME in all these benchmarks. All basic tests that follow are measured against this number unless explici= tly stated otherwise. 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: 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) I have already said the "free" numbers are these mostly only for the fun of= it, haven't I? These numbers seem to differ a lot between Exmap and "free"= =2E One explanation for I have is that they interpret differently what 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 memory (t= he parts that are really in memory), while "free" counts them as part of "c= ached", i.e. not considering them to be a really used memory. I personally = consider the "free" approach to be wrong. In order to use KSycoca, it has t= o be in memory, of course, in order to read the data from it. So it really = takes up some memory. Because it's a read-only mapping, this memory can be = actually discarded whenever needed, so in a way it could be considered the = memory is not really taken, but those data need to be loaded into memory ag= ain when they're needed and this memory is necessary for loading the conten= ts from the file. Besides, repeated loading from disk would be of course ho= rribly slow. If you think this is wrong thinking, just use the same logic w= ith libraries. They are (mostly) read-only mappings of the binaries and the= refore act similarly. And they indeed need to be in memory in order for app= lications using them to work and use them. KDE's base libraries are about 1= 5M 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 people complain ab= out the fact that using any KDE application means loading KDE's libraries i= nto 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 time [http://www.kdedevelopers.org/node/1664]. But the si= ze 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 number seems to = be caused by running way too many processes - even panel applets are separa= te processes. This will have even worse impact later. 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 and o= ne with just shell as the "file manager". 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) Not that big differences really, although generally 4-5 M per application i= s not that little (not though that this includes also the binaries). Window= Maker case is somewhat special in reusing the same application three times = and also generally not being really desktop. 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: 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) 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 in the total va= lue). Window Maker applets are also separate processes, even if quite light= weight. Conclusion for KDE: We should generally try to avoid unnecessary processes.= There should be no need to have a full KDE application for just switching = keyboard layouts and showing an icon. Unlike Kicker applets the systray eve= n encourages this, with the practice of every systray icon being a separate= applet. Even worse, most of systray icons are not even needed 99% of the t= ime - why should KGet be there all the time when it mostly only shows an in= active icon? I've already talked to Aaron about this and the plan is to hav= e special support for such cases that unnecessarily increase memory usage a= nd startup time.=20 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: 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) 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 would have = been without it (and since prelink doesn't change that much about it, peopl= e concerned about memory usage and using prelink should try running KDE wit= hout $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. All the following tests are measured against this case unless stated otherw= ise. 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 + 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)=20 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) 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. 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 + 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) 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 [http://blogs.zdnet.com/Ou/?p=3D1= 39] about Linux desktop being bloated, because a 128M laptop can brought do= wn to its knees by using KDE and running OpenOffice.org? Do these numbers t= ell something about it? 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): 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) 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. 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 usually win. In m= ore complicated cases like this KDE applications even more than compensate = for all the KDE libraries they use and outperform pretty much all competiti= on there is. So, whenever somebody tells us we're lame developers or that C= ++ is much worse language than C, we know it's nonsense. And, as far as the= Window Maker case is concerned, I don't consider that to be competition. T= hat'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: =2D Exmap can be very useful when doing certain memory usage analyses. In c= omparison the usual tools like "free" are often next to useless. Some of th= e "free" numbers above are simply absurd - although they're included becaus= e I measured them, they're not used anywhere. =2D We are never significantly worse than competition. In few cases we are = slightly worse, sometimes we are about the same, but often we are better, s= ometimes even noticeably better. If somebody tells us that we are lame, tha= t C++ or KDE are inefficient or similar things, they should first check wit= h our comparable competition. =2D "Desktops" like Window Maker are not comparable competition. There are = large differences in feature sets and even in concepts. Their users are hap= py with what they have and don't care about KDE, or, in the worse case, the= y badmouth KDE but would never switch anyway. =2D Although our libraries cause us some overhead, like the initial large r= equirements, they are our advantage. They allow us to write good applicatio= ns that are often more lightweight than competition and of course there are= many other benefits like large code reuse, many features and so on. =2D However, there are still areas where we can improve. There are limits, = of course, but we are not near them. --Boundary-00=_GaBBFhGegglr771 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=_GaBBFhGegglr771--