[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-optimize
Subject: Re: Desktop memory usage
From: Lubos Lunak <l.lunak () suse ! cz>
Date: 2006-09-11 23:23:05
Message-ID: 200609120123.06021.l.lunak () suse ! cz
[Download RAW message or body]
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
["memory.html" (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
</head>
<body text = "black" bgcolor="lightblue" link="red" vlink="#ff00ff" \
alink="blue"> <h1>Desktop memory usage</h1>
<h2>Introduction</h2>
<p>
This was actually supposed to be a follow-up to <a \
href="http://www.kdedevelopers.org/node/1663">my</a> <a \
href="http://www.kdedevelopers.org/node/1664">tests</a> of startup \
performance of various desktop environments, primarily KDE of course :). In \
fact 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 \
read than at writing things that people will read :-/ (some volunteer to \
write good user documentation for KWin's window specific settings, BTW ;) \
?) I even meant to make a somewhat more extensive analysis of the numbers, \
but having 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.</p> <p>
These memory benchmarks are meant to measure various cases of desktop \
configuration 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-called lightweight desktop, WindowMaker 0.92.0 as a plain \
window manager and GNOME. GNOME, built using GARNOME, was originally \
version 2.12.2, later redoing it with 2.14.0 (without actually measuring \
noticeable difference in these specific cases, despite 2.14 release notes \
claiming performance improvements). 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.</p> <p>
The tool used to measure memory usage was <a \
href="http://www.berthels.co.uk/exmap/">Exmap</a> - the only tool for \
measuring memory usage that I've ever found to be actually useful (I think \
I've already <a href="http://www.kdedevelopers.org/node/1567">blogged</a> \
about it ;) ). Its so-called effective memory usage numbers try to account \
for things like dividing shared libraries among all the processes using \
them, unlike tools like <i>top</i> that just report the numbers they find \
in <i>/proc</i> and nobody really knows how to interpret them. In other \
words, if you use things like <i>top</i> or <i>free</i> for precise \
measuring of memory usage, you're crazy. Nevertheless, for the crazy ones, \
I used also <i>free</i> alongside with Exmap, just for the fun of it, \
numbers from <i>free</i> will follow in parentheses. They should not be \
considered to be useful though.</p> <p>
The actual measuring was roughly like this: I had SUSE Linux 10.0 running \
in runlevel 3, i.e. without any X started automatically. I started X \
manually myself, with only xterm running. Then I measured total system \
memory usage (total effective memory in Exmap, <i>-/+ buffers/cache</i> in \
<i>free</i>, 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 environment itself. So, let's see the actual \
numbers:
<a name="section1"><h2>1. Plain X</h2></a>
<p>
This number is definitely worth mentioning as well. The case when no \
desktop is running at all, only system daemons, X and xterm. And the number \
is:</p>
<table border=1>
<tr>
<td>31.3 (43.2)</td>
</tr>
</table>
<p>
Yes, more than 30M in use already, according to Exmap (and more than 40M \
according to <i>free</i>, but I myself trust the Exmap number more). \
Effective 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 code that 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 relatively small and is the same for all desktops. \
Although HAL daemon uses some GNOME libraries, due to using GARNOME these \
are different than the ones used by GNOME in all these benchmarks.</p>
<a name="section2"><h2>2. Very plain desktop</h2></a>
<p>
"Very plain" means minimal functionality. In KDE's case there there was \
only the basic desktop and very basic panel applets like the taskbar, pager \
and 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:</p>
<table border=1>
<tr><td>Desktop<td>Usage<td>Diff
<tr><td>KDE<td>60.4 (57.6)<td>29.1 (14.4)
<tr><td>GNOME<td>74.8 (71.2)<td>43.5 (28)
<tr><td>Xfce<td>47.9 (52.6)<td>16.6 (9.4)
<tr><td>WMaker<td>36.9 (47.0)<td>5.6 (3.8)
</table>
<p>
To explain the numbers once more: "Usage" is total memory usage when \
running the specific desktop in the given setup. The first number is from \
Exmap, the one in parentheses is from <i>free</i>. "Diff" is a difference \
to some base state, in this case to the plain X state from <a \
href="#section1">section 1</a>. I.e. it's the memory increase caused by \
running the desktop.</p> <p>
I have already said the <i>free</i> numbers are these mostly only for the \
fun of it, haven't I? These numbers seem to differ a lot between Exmap and \
<i>free</i>. 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 (the parts that are really in memory), while <i>free</i> counts them \
as part of <i>cached</i>, i.e. not considering them to be a really used \
memory. I consider the <i>free</i> approach to be wrong. In order to use \
KSycoca, it has to 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 again when they're needed and this memory is necessary \
for loading 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 binaries and therefore act similarly. And they indeed need to be in \
memory in order for applications using them to work and use them. KDE's \
base libraries are about 15M and if you'd prefer the <i>free</i> thinking \
approach, you'd have to subtract this number from KDE's memory usage. Yet \
of course many people complain about the fact that using any KDE \
application means loading KDE's libraries into memory.</p> <p>
As for the actual results, well, too bad. In fact I had been hoping, \
somewhat naively indeed, that such very stripped KDE would <a \
href="http://www.kdedevelopers.org/node/1664">match Xfce</a> like it did \
with the startup time. 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 number seems to be caused by running way too many \
processes - even panel applets are separate processes. This will have even \
worse impact later.</p>
<a name="section3"><h2>3. Very plain desktop with 3 basic \
applications</h2></a> <p>
Desktops alone are of course not very useful. One needs to run some \
applications to actually make use of the computer. So in addition to the \
very plain 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, KWrite and Konqueror. In GNOME's case they are GNOME Terminal, \
Gedit and Nautilus. 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 \
<i>vi</i> as an editor (sorry Emacs users)and one with just shell as the \
"file manager" - that seems to match what the Window Maker users I know run \
:). Numbers:</p>
<table border=1>
<tr><td>Desktop<td>Usage<td>Diff<td>Very plain diff
<tr><td>KDE<td>75.3 (67.5)<td>44 (24.3)<td>14.9 (9.9)
<tr><td>GNOME<td>90.2 (83.0)<td>58.9 (39.8)<td>15.4 (11.8)
<tr><td>Xfce<td>60.1 (62.8)<td>28.8 (20.5)<td>12.2 (10.2)
<tr><td>WMaker<td>42.2 (51.0)<td>10.9 (7.8)<td>5.3 (4.0)
</table>
<p>
("Diff" is a difference to <a href="#section1">plain X</a>, "Very plain \
diff" is a difference to the <a href="#section2">very plain \
desktop</a>.)</p> <p>
Not that big differences really, although generally 4-5 M per application \
is not that little (note though that this includes also the binaries). \
WindowMaker case is somewhat special in reusing the same application three \
times and also generally not being really desktop.</p>
<a name="section4"><h2>4. Plain desktop</h2></a>
<p>
However, people usually don't use very plain desktops. Besides the basic \
panel applets they often run additional ones, for controlling sound volume, \
showing 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, KXKB, 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 for other desktops (although even now it doesn't 100% match, \
for example I couldn't find any KGet equivalent for Xfce). The numbers \
are:</p>
<table border=1>
<tr><td>Desktop<td>Usage<td>Diff<td>Very plain diff
<tr><td>KDE<td>73.8 (68.1)<td>42.5 (24.9)<td>13.4 (10.5)
<tr><td>GNOME<td>95.3 (90.6)<td>64.0 (47.4)<td>20.5 (19.4)
<tr><td>Xfce<td>48.5 (52.9)<td>17.2 (9.7)<td>0.6 (0.3)
<tr><td>WMaker<td>40.9 (49.7)<td>9.6 (6.5)<td>4.0 (2.7)
</table>
<p>
(Again, "Diff" is a difference to <a href="#section1">plain X</a>, "Very \
plain diff" is a difference to the <a href="#section2">very plain \
desktop</a>. In this case the <a href="#section3">3 applications</a> are \
not running</a>.)</p> <p>
More than 10M for 8 applets isn't very impressive. The number could have \
been 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 libraries). 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 total value). Window Maker applets are also \
separate processes, even if quite lightweight.</p> <p>
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 \
before doing this test.</p> <p>
<b>Conclusion for KDE:</b> 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 even 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 time - why should KGet be there all the time when it mostly only \
shows 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.</p>
<a name="section5"><h2>5. Desktop with 3 basic applications</h2></a>
<p>
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:</p>
<table border=1>
<tr><td>Desktop<td>Usage<td>Diff
<tr><td>KDE<td>85.8 (72.3)<td>54.5 (29.1)
<tr><td>GNOME<td>110.4 (103.0)<td>79.1 (59.8)
<tr><td>Xfce<td>58.3 (61.0)<td>27.0 (17.8)
<tr><td>WMaker<td>51.4 (59.7)<td>20.1 (16.5)
</table>
<p>
("Diff" is difference to <a href="#section1">plain X</a>.)</p>
<p>
KDE here could do somewhat better with applets handled differently. There \
probably can't be done much with the big increase caused by KDE libraries, \
there 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 \
use of <i>kdeinit</i> these numbers are still noticeably lower than they \
would have been without it (and since <i>prelink</i> doesn't change that \
much about it, people concerned about memory usage and using <i>prelink</i> \
should try running KDE without <i>$KDE_IS_PRELINKED</i> set).</p> <p>
Xfce in these basic tests performs excellently, almost keeping up with \
Window Maker while actually being a desktop and not just a window manager \
with few applet apps and several terminals. Its integrated applets and \
basic applications 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 to look elsewhere doesn't show yet.</p>
<a name="section6"><h2>6. Web browser</h2></a>
<p>
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 \
applications work when not in their native desktop I measured all of them \
in all desktops:</p>
<table border=1>
<tr><td>Desktop + browser<td>Usage<td>Diff
<tr><td>KDE + Konqueror<td>95.3 (83.8)<td>9.5 (11.5)
<tr><td>KDE + Firefox<td>108.0 (90.4)<td>22.2 (18.1)
<tr><td>KDE + Epiphany<td>112.5 (91.5)<td>26.7 (19.2)
<tr><td>GNOME + Epiphany<td>127.7 (114.6)<td>17.3 (11.6)
<tr><td>GNOME + Firefox<td>133.6 (118.8)<td>23.2 (15.8)
<tr><td>GNOME + Konqueror<td>136.5 (113.3)<td>26.1 (10.3)
<tr><td>Xfce + Firefox<td>80.2 (73.2)<td>21.2 (12.2)
<tr><td>Xfce + Epiphany<td>82.6 (72.4)<td>24.3 (11.4)
<tr><td>Xfce + Konqueror<td>84.4 (71.6)<td>26.1 (10.6)
<tr><td>WMaker + Firefox<td>69.9 (65.9)<td>18.5 (6.2)
<tr><td>WMaker + Epiphany<td>74.3 (65.9)<td>22.9 (6.2)
<tr><td>WMaker + Konqueror<td>80.2 (65.1)<td>28.8 (5.4)
</table>
<p>
("Diff" is difference to <a href="#section5">desktop with 3 basic \
applications</a>, i.e. it is the memory increase caused by running the \
browser.)</p> <p>
Here some numbers that one would expect to be the same (e.g. Firefox in \
various desktops) vary a bit, partially due to various reuse of libraries, \
partially probably due to "noise". Although the numbers are stated with \
precision to one decimal place, you're crazy if you don't round them up a \
bit more - this is benchmarking, not mathematics. The only number that \
seems to be somewhat strange is Firefox in Window Maker where the change is \
smaller than in other desktops. It may be a mistake on my side (which I \
can't check anymore) or perhaps some desktop-specific support in Firefox \
that doesn't get activated in Window Maker.</p> <p>
Konqueror in this case actually happens to cheat a bit, since the basic \
Konqueror 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 for 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 clear 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 were no preloaded Konqueror instances.</p> <p>
Interestingly enough using Epiphany in KDE needs more memory than Firefox. \
The same effect like with loading KDE libraries shows here, Epiphany \
apparently 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 libraries.</p>
<a name="section7"><h2>7. Office suite</h2></a>
<p>
This is very similar to the web browser case, this time with KWord from \
KOffice, Writer from OpenOffice.org and Abiword, all of them showing a \
simple document.</p>
<table border=1>
<tr><td>Desktop + suite<td>Usage<td>Diff
<tr><td>KDE + KWord<td>100.0 (81.5)<td>14.2 (9.2)
<tr><td>KDE + OOWriter<td>166.7 (110.5)<td>80.9 (38.2)
<tr><td>KDE + Abiword<td>102.2 (85.4)<td>16.4 (13.1)
<tr><td>GNOME + Abiword<td>121.4 (117.8)<td>11.0 (14.8)
<tr><td>GNOME + OOWriter<td>196.3 (138.1)<td>85.9 (35.1)
<tr><td>GNOME + KWord<td>140.9 (115.3)<td>30.5 (12.3)
<tr><td>Xfce + OOWriter<td>142.1 (96.5)<td>83.8 (35.5)
<tr><td>Xfce + Abiword<td>77.1 (68.7)<td>18.8 (7.7)
<tr><td>Xfce + KWord<td>89.4 (72.3)<td>31.1 (11.3)
<tr><td>WMaker + OOWriter<td>124.7 (90.8)<td>73.3 (31.3)
<tr><td>WMaker + Abiword<td>64.8 (62.0)<td>13.4 (2.3)
<tr><td>WMaker + KWord<td>76.7 (66.0)<td>25.3 (6.3)
</table>
<p>
("Diff" is difference to <a href="#section5">desktop with 3 basic \
applications</a>, i.e. it is the memory increase caused by running the \
office suite.)</p> <p>
OpenOffice used support for both KDE and GNOME, so the numbers vary in \
different desktops. I originally wanted to embed a table from the matching \
spreadsheet counterpart, but I didn't find out how to embed a table from \
Gnumeric 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.</p> <p>
Numbers show that applications running in their home desktop have the \
smallest memory increase, as they reuse the desktop's resources. This \
however still doesn't completely compensate for the overhead of the \
libraries, although there are of course differences in functionality, so no \
good comparison can be made. Similarly the comparison to OpenOffice.org is \
not completely fair because although other office suites provide similar \
functionality to it they don't provide as extensive set of features as \
OpenOffice.org .</p> <p>
By the way, do you remember the <a \
href="http://blogs.zdnet.com/Ou/?p=139">complains</a> 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?</p>
<a name="section8"><h2>8. Desktop's applications</h2></a>
<p>
This one admitedly may look a lot like I'm trying to cheat. In this case \
KDE running KDE applications, GNOME running GNOME applications and Xfce \
running generic applications will be compared. Xfce will be running generic \
applications 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 \
Evolution and Xfce will be accompanied by the most known independent \
applications, that is Firefox as a web browser, OpenOffice.org as office \
suite and Thunderbird a mail client.</p> <p>
And that's where the problem is. As shown above, OpenOffice.org can \
"outperform" 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 libraries 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):</p>
<table border=1>
<tr><td>Desktop<td>Usage<td>Diff
<tr><td>KDE + KDE apps<td>143.2 (117.7)<td>111.9 (74.5)
<tr><td>GNOME + GNOME apps<td>174.8 (149.3)<td>143.5 (106.1)
<tr><td>Xfce + 3rd party apps<td>206.8 (135.7)<td>175.5 (92.5)
</table>
<p>
("Diff" is difference to <a href="#section1">plain X</a>, i.e. it is the \
memory increase caused by running the desktop and all the \
applications.)</p> <p>
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 \
after adjusting, it's not going to win. The difference between KDE and Xfce \
here 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 \
would however mean OpenOffice.org almost reaching resource usage of \
KOffice, which seems very unlikely, no matter how you look at it - 3rd \
party app using its own toolkit and everything simply shouldn't be able to \
be as lightweight as KOffice which heavily reuses parts of KDE. So let's \
say that the Xfce value shouldn't be less than 150M - that still makes Xfce \
lose in the end. The same thing that handicaped KDE in the beginning by \
causing big initial usage eventually lead to lightweight applications that \
compensated for it.</p> <p>
If you still don't quite like this test, simply consider it as another \
reason for the existence of KDE. KDE here is the integrated solution using \
one framework. Xfce here ended up demonstrating the state of pretty much \
everybody rolling their own solution. Showing this was the point of this \
test.</p> <p>
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 \
something about the possibility of running GNOME applets in-process, so \
GNOME developers should seriously consider doing this. However, even when \
ignoring this, GNOME still falls even more behind KDE in this last test. \
Epiphany is more demanding than Konqueror, Abiword is slightly more \
lightweight than KWord (although using components would most probably turn \
it around in favour of KOffice) and after summing up all the numbers it \
seems that Evolution is also more demanding than Kontact.</p> <p>
<b>Conclusion for KDE:</b> When comparing applications, KDE ones often win. \
In more complicated cases like this KDE applications even more than \
compensate for all the KDE libraries they use and outperform pretty much \
all competition 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. That's a different league with different \
users and different use cases.</p>
<h2>Conclusion</h2>
<p>
Ok, that's it. I tried quite hard to get these numbers and make sure \
they're usable. I however cannot rule any possible mistake and I'm \
obviously biased, 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?). 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 really simple to do them incorrectly, trust me). \
In fact, since this is actually several months old, it would be nice if \
somebody tried with GNOME 2.16 and saved me the work.</p> <p>
The things we should learn from this:
<ul>
<li>
Exmap can be very useful when doing certain memory usage analyses. In \
comparison the usual tools like <i>free</i> are often next to useless. Some \
of the <i>free</i> numbers above are simply absurd - although they're \
included because I measured them, they're not used anywhere.</li> <li>
We are not significantly worse than competition. In few cases we are \
slightly worse, sometimes we are about the same, but often we are better, \
sometimes even noticeably better. If somebody tells us that we are lame, \
that C++ or KDE are inefficient or similar things, they should first check \
with our comparable competition.</li> <li>
"Desktops" like Window Maker are not comparable competition. There are \
large differences in feature sets and even in concepts. Their users are \
happy with what they have and don't care about KDE, or, in the worse case, \
they badmouth KDE but would never switch anyway. The same way our users are \
unlikely to switch because Window Maker is not a desktop from our point of \
view.</li> <li>
Although our libraries cause us some overhead, like the initial large \
requirements, they are our advantage. They allow us to write good \
applications that are often more lightweight than competition and of course \
there are many other benefits like large code reuse, many features and so \
on.</li> <li>
However, there are still areas where we can improve. There are limits, of \
course, but we are not near them.</li> <li>
Processes are in desktops are usually relatively heavy. This is caused by \
the various initializations done for GUI applications. Some of them are \
inefficiencies in our code and should be improved, some of them are \
problems of non-KDE code we depend on (like the already-mentioned <a \
href="http://www.kdedevelopers.org/node/1495">fontconfig problems</a>), but \
some of them cannot be avoided (it's simply unrealistic to have specific \
code for each KDE application). Since such inefficiencies affect every KDE \
application, their impact should be minimized. The number of running KDE \
applications should be also kept generally low - either techniques like \
KDED modules and similar should be used, or, when possible, some processes \
should be avoided altogether.</li> </ul>
</p>
<hr>
Lubos Lunak <l.lunak@kde.org> <l.lunak@suse.cz>
</body>
</html>
_______________________________________________
Kde-optimize mailing list
Kde-optimize@kde.org
https://mail.kde.org/mailman/listinfo/kde-optimize
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic