MAY
9
2001

An Analysis of KDE Speed

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.


By Bojan at Wed, 2001/05/09 - 5:00am

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 AC at Wed, 2001/05/09 - 5:00am

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


By BillyBoy at Thu, 2001/05/10 - 5:00am

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.

Shridhar


By Shridhar Daithankar at Wed, 2001/05/16 - 5:00am

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


By Con Kolivas at Thu, 2001/05/10 - 5:00am

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 Chad Frick at Sat, 2001/05/12 - 5:00am

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.


By rev_matt at Wed, 2001/05/09 - 5:00am

"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 AC at Wed, 2001/05/09 - 5:00am

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 sarang at Wed, 2001/05/09 - 5:00am

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


By DC at Wed, 2001/05/09 - 5:00am

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 me at Thu, 2001/05/10 - 5:00am

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 Idiot-buster at Thu, 2001/05/10 - 5:00am

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


By Tick at Thu, 2001/05/10 - 5:00am

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 AC at Fri, 2001/05/11 - 5:00am

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 dc at Wed, 2001/05/09 - 5:00am

Hi,

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 Sam at Wed, 2001/05/09 - 5:00am

I already did that. Gnome is much faster though.


By dc at Wed, 2001/05/09 - 5:00am

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 Shaleh at Wed, 2001/05/09 - 5:00am

Hi!

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

Greetinx,

Gunter Ohrner


By Gunter Ohrner at Wed, 2001/05/09 - 5:00am

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 KDEuser at Thu, 2001/05/10 - 5:00am

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 Gunter Ohrner at Fri, 2001/05/11 - 5:00am

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"

-Karl


By Karl Garrison at Wed, 2001/05/09 - 5:00am

Good idea. I'll look into it.

Cheers,
Navin.


By Navindra Umanee at Thu, 2001/05/10 - 5:00am

I wish I had a million dollars.


By ac at Fri, 2001/05/11 - 5:00am

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

sarang


By sarang at Wed, 2001/05/09 - 5:00am

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


By Schwann at Wed, 2001/05/09 - 5:00am


By Evandro at Wed, 2001/05/09 - 5:00am

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


By robert at Wed, 2001/05/09 - 5:00am

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 Herbert Graeber at Wed, 2001/05/09 - 5:00am

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 ik at Wed, 2001/05/09 - 5:00am

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 Daniel at Wed, 2001/05/09 - 5:00am

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 AC at Wed, 2001/05/09 - 5:00am

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


By jed at Fri, 2001/05/11 - 5:00am

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


By itsme at Wed, 2001/05/09 - 5:00am

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 dc at Wed, 2001/05/09 - 5:00am

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

--Garion911


By gairon911 at Wed, 2001/05/09 - 5:00am

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

Bye,
Carsten


By Carsten Schmidt at Wed, 2001/05/09 - 5:00am

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 dc at Wed, 2001/05/09 - 5:00am

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 Charles Samuels at Fri, 2001/05/11 - 5:00am

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 not me at Fri, 2001/05/11 - 5:00am

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 Charles Samuels at Sat, 2001/05/12 - 5:00am

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

This is not a troll.

regards.


By thil at Wed, 2001/05/09 - 5:00am

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 Theo van Klaveren at Wed, 2001/05/09 - 5:00am

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


By AC at Thu, 2001/05/10 - 5:00am

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


By R.Ganesh Kumar at Sun, 2004/12/12 - 6:00am

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 _linCE at Wed, 2001/05/09 - 5:00am

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 Stuart Herring at Thu, 2001/05/10 - 5:00am

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 _linCE at Thu, 2001/05/10 - 5:00am

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:

http://lwn.net/1998/1029/als/rope.html

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

Bye,
Stefan Heimers


By Stefan Heimers at Thu, 2001/05/10 - 5:00am

I found some more info about those tools:

SCO has one called fur

http://uw7doc.sco.com/SDK_cdebug/_Using_fur_to_Perform_Block_Prof.html

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

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

http://lists.gnome.org/archives/gnome-hackers/2000-October/msg00116.html

The author of grope is called Nat Friedman. His email adress is nat@nat.org.

This seems to be his homepage:
http://www.nat.org
But it doesn't look very useful for any code optimization ;-)

And there are some magic point presentation slides:
http://www.hungry.com/~shaver/grope/slides/

http://www.tux.org/hypermail/linux-kernel/1999week30/0290.html

I still did not find any code :-(

Bye,
Stefan Heimers


By Stefan Heimers at Thu, 2001/05/10 - 5:00am

Pages