Many aspects of KDE performance depend on the underlying system or the user's configuration. The KDE Performance Tips document, which lists some of the performance related issues together with instructions how to avoid or fix the problems, has been updated with new tips. If you would like to add new tips to this page, update the ones already listed, or discuss them, please use the kde-optimize@kde.org mailing list. Note that this list is for working on optimizing KDE -- not for complaining.

Comments

Gee, why have I bothered to ask that content changes are first discussed on the kde-optimize list then? Both here and in the page itself?

It is a wiki page because ... er ... it happens to be a wiki page. It started as wiki page one day. But people should not just go and add what they _think_ helps KDE performance, because, quite frankly, some people have strange ideas about KDE performance. Even people who work on performance often think wrong, until they get to measuring. If you have a new idea, and can back it up with some proof, post it to the list, and you'll get okay for including it.

If the page turns into a bunch of I-think-this-might-perhaps-help's, I'll move all my tips to somewhere where only I will be able to do anything with it. There is quite some work behind them.

Of course, people are free to edit it. Assuming they add something good and useful. But since optimization is a difficult beast, nobody finds out new (and correct) things somehow spontaneously, they need to be examined and checked -> that's why it should be reviewed first. And BTW, it actually wasn't me who put up the page.

No, of course it's stell better to achieve an authentic improvement in execution speed.
However, in places where this simply can't be done, be it because of lack of information about the problem, or because of bottlenecks in software on which KDE depends (gcc / ld, qt, etc), it is at least desirable to give a user an *illusion* that things are happening faster - so to say, build up a psychological solution for a technical problem.

He'll be completely happy with this, because he *thinks* it's going faster, and that's all he needs.

Simple example: Imagine you right-click somewhere, which causes an application to open a menu.
Now the program could:

- load all items, load all icons, construct the menu, then show it.

or

- *show* the (empty) menu (border), an fill it up with items and icons which get loaded one by another.

This makes a user way more satisfied than having to wait for a second to get a menu after having clicked somewhere.

Of course, the menu-drawing-and-lading-code has still to be optimized. The psychological solution should not replace technical solutions, after all.

To take that example a little further, the method would appear the fastest would be to have a pretty way of drawing the menu which takes little power and seems intentional.

The first method you noted (plan it all out, then draw it) takes less time but has a high latency, which makes the user feel like the computer is non-responsive. However, having part of the menu appear, then another part, then another, leaves the user thinking the computer is having trouble actually drawing the menu, making them think it is either badly written software or that their system is overworked (which may be the case).

By contrast, the menu could be drawn by first causing the menu top to extend out horizontally from the cursor, giving a head to the menu, then, when the vertical height of the menu is determined, having it extend smoothly downwards, as if it were sliding down. And, finally, have the contents swiftly fade in.

The method I just described could all happen almost instantaneously if the menu was ready, but would cause minor slowdowns in all cases. However, it would appear to be intentional, so the user would be less likely to think the system was having trouble. Also, it'd be purty.

It helps a lot on my system (400Mhz celeron with slackware)!
For example, kmail used to need more than 10 sec to
startup, with prelinking my whole system, this time
is reduced to less than 5 sec. And I only took kmail
as an example, all applications start faster.
Also don't forget to set KDE_IS_PRELINKED or something.
The command I use is: prelink -avmR
And /etc/preling.conf looks like:
-l /bin
-l /usr
-l /sbin
-l /lib
-l /opt

There are a few nasty memory leaks on the various sites that run on this server. That seems to have caused MySQL to corrupt one of its tables. I tried to repair the table in MySQL... the frontpage of the wiki now seems to be screwed. :(

Quote from the wiki: "A mechanism for the Linux kernel is currently being developed that will precache disk contents needed during startup."

That one sounds really interesting. even more interesting than the kdm-preload feature, which I also didn't know about before :)
Any pointers where I can find out more about that? Is such a mechanism really going to be included into the kernel? I heard about several attempts for precaching, but obvisously none of them got very far.

You probably can't find out more about that these days. It is developed by one of the SUSE kernel developers, it's not ready yet, and I can't give you any estimate when it will be (and I also can't guarantee it won't be just like the other attempts). Optimizations usually aren't of the highest priority :-/ .

- is there any option in KMail to display smiley graphics (like in th-bird/opera-m2) instead of display ':-)'? (should be in text mails too)

- is there any option in KMail to have only in KMail Firefox the default program for http/-s and ftp links? it's not nice to open konqueror and after typing in 'www.google.com' konqui opens Firefox ;-) (there are moments when I want to surf with konqueror)

- is there any option in KDE to have the desktop icons placed at that place where there are before I logout/rebooting? I tried different options in context menu (snap to grid?) but doesn't help. Or if I move one 'non-kde' Icon (eg firefox icon) all icons on my desktop moves some pixels down (if I have snap to grid turned on)