An Analysis of KDE Speed

Our recent poll (courtesy on the upcoming KDE 2.2 suggests that the area of
greatest concern for KDE users is speed -- at this time, out of 3,463 votes, over 24% consider speed as most important for developers to address. Waldo Bastian, who developed the kdeinit speed hack among other things, has written a paper entitled "Making C++ ready for the desktop", in which he analyzes the various startup phases of a C++ program. Noting that one component of linking -- namely, library relocations -- is currently slow, he offers some suggestions for optimizations. An interesting read.

Dot Categories: 


by Bojan (not verified)

Look at it this way:
when did the development of Windoze start? And when did KDE development start? Do you know, how many payed programmers Microshit has for Windoze development? And how many volunteers work for free on KDE? Even if you neglect this questions, you should answer this: let's say I give you few hundred bucks. You have a slow computer with no OS on it at the moment. You may buy a Windoze license or you may buy new hardware (only processor and RAM) that will run KDE faster. Which one will it be and which one will run faster now? OK, let's get a bit more serious. KDE offers great platform for application development, because it is written in pure C++ and it offers great technological advantages (like KParts, DCOP, etc.). It was written in C++ for that reason. Would the only reason be speed, it would probably be written C like GNOME. Speed is important, but KDE guys did what they could to speed it up as it is obvious from Waldo's article. If you care so much for speed, then maybe you should check back about KDE in few months.

by AC (not verified)

Binaries from C-Code or from C++ are likely to be different in speed (maybe in size, plain C intends to result in bigger executables than C++). It's really the startup-time, that matters!

What we should talk about instead:
How can we improve the dynamic linker?

p.s: It's just a feeling, but I think windoze has it's advantages in speed by putting up with technological disadvantages.

by BillyBoy (not verified)

nevertheless the shit is faster than "the solid rock"...

by Shridhar Daithankar (not verified)

My 2 cents.

Windows GUI is fast but it's speed varies depending upon the load. That happens *very* rarely with KDE.

I use 256MB machine with win2K. When netscape is going thr. thousands of messages and I try starting IE or something like that, it takes more time than to start IE+netscape separately.

Windows GUI has advantage of speed. But KDE is certainly more productive.

Besides on Mandrake 8, KDE is at least as fast as w2k.


by Con Kolivas (not verified)

Agreed, and I have a relatively fast PC and find the same things you do.

by Chad Frick (not verified)

Yes, go ahead and go back to Windows. I hope you enjoy digital content protection.

(And yes, I posted this using Windows. I don't feel like building a cross-compiler right now.)

by rev_matt (not verified)

Speed is the number one reason I don't like KDE. Gnome is and will remain my desktop on my KRUD ( boxes. The only system I use KDE on is my laptop, and only because Ximian hasn't released a Mandrake 8.0 version yet. I can't have more than three windows (two mozilla windows, an evolution window, and a terminal window stop the box completely) and this is a pIII-600 with 192M of RAM. Win2k runs faster.

by AC (not verified)

"two mozilla windows, an evolution window, and a terminal window"

lol... I'm sure it's not the terminal, that causes your system to slow down ;)

by sarang (not verified)

this is rediculous.. what are you talking about? I have a Dell 5000e and at 400x1050, the memory used max goes till 70MB or so.. That means it should be very much possible to work even on a 64MB box. And yes, this is after i open tons of KDE applications.

by DC (not verified)

Then I have to ask: What company are you working for ? What's your relationship with M$ ?

by me (not verified)

Thats bollocks.
I'm running a PIII700 196 meg memory, with 2 Xservers (one running on :0 and the second on :1). On the first theres Evolution, Galeon, many terminal windows, emacs, and numerous other windows. On the second Xserver theres wine running Starcraft.

Now, if 2 mozilla windows, Evolution and a terminal (thats 4 windows BTW), "stop the box completely" I suggest it's probably not the software (either KDE or GNOME) at fault.

by Idiot-buster (not verified)

You perception of REALITY is far from the truth. In an attempt to make KDE crash, I loaded one Konq. with the root directory as the view. I then clicked on the Konq. spinning icon to respawn new Konq.s. After clicking as fast as I could until I got bored with it, I fired up a breakout game and played it as I watched all these windows being drawn to the screen. I eventually had 73 Konqs open!!!! I then closed all these windows as fast as I could, and KDE didn't crash.

This is on a P11 400 with 128mb RAM

I love KDE, I would gladly buy a second 128mb DIMM and have the entire KDE run from ram if that was possible. Then the speed issue would be nul and void, for me at least.

by Tick (not verified)

that's not 73 konqs. That's 73 konq windows, with 1 konq process.

by AC (not verified)

Of course if you knew anything about how a computer works, you'd know that 1 konqueror and 1 mozilla has a better chance of breaking something than 73 konqs(this is not a joke about mozilla, assume mozilla takes the same resources as konq for this, and don't reply anything about mozilla).

by dc (not verified)

I voted for speed.
But the "speed" I was referring to is not only startup time, but also other things.
Show a menu for example.
I have a Pentium 166 MMX with 48 MB RAM.
Clicking on the menu button takes 1 - 2 seconds before the menu actually shows up.
Same goes for the menus in KDevelop.
They are slower than other KDE/QT program menus for some reason.

by Sam (not verified)


Try to adjust the cache settings in kde so it don't cache so much in memory. Also try to stop so many services (/etc/rc.d/init.d) so you can free up as much memory as possible. Big fat background images is not for you either :(

by dc (not verified)

I already did that. Gnome is much faster though.

by Shaleh (not verified)

I agree 100%. Start up times are annoying, but it is actual runtime speed that makes users really annoyed. The simple act of using the UI feels sluggish. This is without themes, backgrounds (I tend to use a single color or sometimes a gradient). My machine also runs next to nothing other than X. sshd is the only daemon likely to be active at any one point in time.

I see people say that come on you can always buy a faster box. Must be nice to have money to throw away. Machines are still not free, nor can I just magically make my laptop 3 times faster. But I should not need to either.

by Gunter Ohrner (not verified)


Additionally to freeing up memory as suggested in the other reply to your post you could try to play with the X servers setting. With 48 MB RAM you could try to disable double buffering for example and see if that *helps*! (Should give a quite a few bytes free RAM if you'r video RAM is relatively small.)


Gunter Ohrner

From personal experience, RAM doesn't make a difference. I have 128mb of RAM and the experience I have is still slow. In all honesty, running Win95 on a 486 with 32mb RAM (my old PC)is faster than KDE on a P11 400 with 128mb RAM .

This really is not acceptable.

by Gunter Ohrner (not verified)

RAM *DOES* make a difference! It's true Win95 uses much less of it, a linux system running X and KDE needs *tons* of RAM, 128 MB is still a bit few.
You could upgrade to 192 MB or 256 MB RAM which should improve the response time of your system and you can check the widget theme you are using. Never import GTK themes into KDE as this will *KILL* performance, there is an enormous ressource leak related to this "feature" of KDE.

by Karl Garrison (not verified)

I wish when posting comments, the subject field would default to blank unless one is replying to an individual's post. This way, threads will likely have more useful subject lines, instead of the current situation where 90% of the posts for this topic have a subject line of "Re: An Analysis of KDE Speed"


by Navindra Umanee (not verified)

Good idea. I'll look into it.


I wish I had a million dollars.

by sarang (not verified)

Won't it be cool to have a wizard that shows step by step setting that could be changed to reduce memory footprint and increase speed?

The wizard could check the system's memory and give suggestions. For eg. the caching of wallpapers could be tunrned off for low memory machines etc..


by Schwann (not verified)

I heard that gcc 3.0 will improve C++. But I don't know what kind of improvement.
Does anybody of you know?

by Evandro (not verified)
by robert (not verified)

GCC 3.0 will be more standards complient, the problem is that linker, not the compiler.

by Herbert Graeber (not verified)

No, it it's not only the linker. If gcc would produce more relocatable code, using relative adresses for example, the linker has do do less relocation.

by ik (not verified)

interesting ... could someone with gnuc 3.0 compiled kde do those relocation statistics (LD_DEBUG=statistics and so) and compare with those in the paper ?

by Daniel (not verified)

I can't help thinking sometimes that KDE is a victim of its own sucess. Most of the biggest problems with KDE come from the X server (bloat) and the underlining system (slow loading of libraries).

The abilty to handle protocols like cdrom:// and kamera:// is a great feature but features like like belong in the underlying system.

Maybe its time that KDE starts to think about contributing to these underlying systems?

by AC (not verified)

Please read the TOP documentation, X runs on IPAQs very smoothly. There is no better known algorithm to relocate funtion pointers, performance can only be increased slightly, the only fix for this is to use less virtual functions, which may never hapen because Qt is not developed specificly for KDE. Protocols like cdrom, kamera should not be bound to any underlying system, not only is that poor design, they are dependant on Qt. The problems with KDE are KDE's fault(It's a very good desktop thought).

by jed (not verified)

Please don't post anymore unless you want to look stupid again.

by itsme (not verified)

Would statically linking applications instead of using shared libraries improve the performance? I mean, would that avoid most, if not all, of the bottleneck?

by dc (not verified)

That would most likely make the situations worse.
Unlike what many people think, statically linked apps are NOT the solution.
Statically links apps don't share memory, thus making the footprint much higher.
Because of that, the swap must be accessed more often, causing major slowdowns.

by gairon911 (not verified)

Now that there's a central way of starting applications, I'm wondering if someone could implement an object pooling/caching mechanism like EJB containers do... Imagine the increased speed if the various objects are already created, and just stored in memory and/or disk..

I'd also be curious about the various programming patterns that have been applied, if any.. Maybe some more effiecent patterns designed to reduce the number of ojbects could help..

Please note I'm not a KDE developer, nor have I looked at the code, but I am planning on it, as there's some bugs that are annoying the hell outta me right now...


by Carsten Schmidt (not verified)

I was talking to one of the KDE developers at the "3rd Braunschweiger Linux Tage" (I forgot his name). He told me that Qt is faster than gtk+.
However I can not verify this statement since on my machine (amd 500MHz) gtk+ runs A LOT smoother than any Qt program (even without KDE).


However if I can look at the widgets drawing I will stick on enlightenment 0.16 and wait for 0.17 to introduce evas which draws 115 frames/s on my box.

I think KDE Speed depends on how you compile the whole thing. All approaches I tried did not seem to make KDE any faster.

I would appreciate if anyone of the KDE developers could make a KDE-Compile-HOWTO that discusses various problems...


by dc (not verified)

I simply don't understand how QT is faster.
Sure, the themes might draw a little faster, but what's a few miliseconds?
Even on my old Pentium 166 I don't notice any difference.

by Charles Samuels (not verified)

There's a noticable difference, on my dual P2/300, using the Legacy GTK-style importer, GTK themes are significantly faster in Qt, then they are in GTK.

by not me (not verified)

Wow! You got the GTK theme importer to work!? How? All it does for me is cause KDE to crash and print out lots of "Unknown object GTKCurve" messages or something like that.

by Charles Samuels (not verified)

I just tried it on the GTK-default (the only theme I have for GTK ;), and it works.. just not very well. Maybe it just can't make sense of the style you selected?

by thil (not verified)

Do you know if there is any plan
to port KDE to QT embeded ?

This is not a troll.


by Theo van Klaveren (not verified)

Heh, your question is a bit off-topic, but not a troll in any way (the word 'troll' seems a bit over-used lately anyway)...

To answer your question: I know of at least some work to port Konqueror to Qt-embedded, take a look at kde-nox in CVS.

by AC (not verified)

If you mean for speed enhancement on a PC, loosing hardware acceleration will slow things down.

by R.Ganesh Kumar (not verified)

Hello Sir ,

I am ganesh kumar Doing B.Tech I.T In Sakthi mariamman Engg College

Chennai ( Tamilnadu , INDIA) . I need the List of Project Title & Thier Ideas .

PLEASE Reply me..................

by _linCE (not verified)

In my honest opinion, KDE is very slow. KDE improved in startup from 1.x to 2.x series, but... the general use of it is lots and lots of hard disk and RAM usage.
Another negative aspect about KDE is the way you install it. Tarball and compilation time are the longest i've ever seen, it could take a week.
(thanks RPM's).
The suite is very extreemely integrated, having endless dependencies/libraries split in several packages. I would prefer to have a kde-whole.tar.gz of 50 MB and ./configure --disable-koffice --disable-graphics --disable-toys --disable-junk etc etc etc.......

by Stuart Herring (not verified)

That's just wrong..

The only real dependency is that you need to compile kdelibs first....

every other kde package will then compile in any order you wish...

by _linCE (not verified)

I might have slid away in my comment about dependecy. But my concern is mostly about SPEED. And KDE 2.x and OpenOffice are the most SLUGGISH things I ever seen. Something is wrong. Compilation takes a LOT of time. Or am I wrong too?

by Stefan Heimers (not verified)

Does anybody know what happened to GNU Rope (grope)? It is a GNU replacement for SGIs cord.

The trick is to rearrange functions in binaries and libraries in groups often used together or in order of first call. This makes disc cache more efficient and uses less memory pages.

They claim to save 30% memory and could double speed. Unfortunately I only found a description, but no code or binaries.

Here is a description:

If you do not find grope keep in mind:

- Functions used at program start should be grouped in order of their first call -> makes disc cache more efficient -> reduces load time

- Functions often used together should be located close to each other in binaries. If they fit in the same page of memory "load on demand" needs to load less pages. -> Faster and less memory usage

Stefan Heimers

by Stefan Heimers (not verified)

I found some more info about those tools:

SCO has one called fur

The Intel-Compiler also can use runtime profiling information to optimize linking.

You might also want to have a look at the following pages:

The author of grope is called Nat Friedman. His email adress is [email protected].

This seems to be his homepage:
But it doesn't look very useful for any code optimization ;-)

And there are some magic point presentation slides:

I still did not find any code :-(

Stefan Heimers