[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