[13:17:58] <Seli> boy, this machine sucks ... how am I supposed to benchmark anything if it fires up KDE in 3.7 seconds?
Yeah, right, it's kinda stupid to work on performance when the machine is so fast that even sysprof sometimes doesn't produce enough samples and the machine has no support for CPU throttling or anything like that :(. I'll need to transfer the build from this AMD 2800+ to this slow 900MHz laptop I used at aKademy for the performance talk. Note that while I cheated a bit at aKademy, this is normal KDE startup. Still with warm disk caches, but fc-list says 249 fonts, I have a splash (the SUSE one, that is, ksplash is not exactly fast), I have a wallpaper, and while it is a bare KDE it is fully usable. And adding Konqueror, KWrite, Konsole and some of the default systray apps to the startup still keeps it slightly below 5 seconds. I'm curious what the laptop will do.
Anyway, since I've already posted some details about this two times and I don't feel like doing it more than once more, let this place be the once more time. So, for those who feel like asking, various copy&paste from IRC:
[14:11:51] <Seli> [13:54:49] <Seli> actually, I can do a measurement for estimating to maximum impact of -Bdirect
Actually now I think the 30 is a better guess, and while -Bdirect can never achieve as much as prelink from principle it should actually be possible to get quite close. Close enough not to make a difference in practice. I guess my belief that prelink would be a better solution is because I find prelink a "cleaner" solution ... which may be both wrong and naive ... and I can be sometimes naive when it comes to choosing practical solutions. Let's say that with -Bdirect we would spend somewhere less than 10% in relocation processing. Note that while this is an educated guess it's still only a wild guess.
Another advantage of prelink would be saving more memory because of less dirty pages caused by relocations, but a) because of conflicts prelink is far from causing no dirty pages at all and fixing those would be non-trivial amount of work, b) kdeinit takes care of it anyway.
As long as we don't spend 1/3 of startup time in the dynamic linker I guess it doesn't really matter in practice how it gets fixed.
Note that all these numbers are for tests with warm disk caches. When KDE has to read all the things from the disk KDE startup takes several times longer. Improving this would need kernel support and/or various preloading techniques.
PS: No, you can't achieve the same startup speed yet. You'd need latest (unstable) fontconfig, few patches and so on. But don't worry, that'll eventually get to you (as far as fontconfig/Qt/KDE are concerned, I can't say about the rest of things KDE would need for better performance).
PPS: Coolo has a nice bootchart picture showing KDE startup.
con kolivas is helping too :D
con kolivas is helping to get adaptive-readahead stable (his first announcement: http://bhhdoa.org.au/pipermail/ck/2005-October/004684.html). this might help in the 'cold' startup time...
Nice one Lubos!
Nice one Lubos!