Our recent poll (courtesy KDE.com) 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.

Comments

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.

Speed is the number one reason I don't like KDE. Gnome is and will remain my desktop on my KRUD (www.tummy.com/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.

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.

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.

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.

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

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.

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

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.

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

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 .

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.

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"

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

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.

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

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

IMO, KDE is THE BEST/MOST STABLE and MOST FEATURErich desktop.

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

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

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?