5 seconds ... ok, 6

Yes, I could really make KDE start up in just 5 seconds on a 900MHz laptop ... 6 seconds during the presentation, the laptop apparently decided to spend the extra second somewhere. As it was measured using a wristwatch it doesn't matter much anyway. And you can download the video, see it for yourself and measure it yourself.

And it wasn't even crippled KDE, not really. I turned off pretty much everything I didn't need, but it was still a fully usable KDE. The only things that really were kind of cheating was using just 5 fonts (because fontconfig sucks perfomance-wise), creating empty ~/.XCompose fonts (same comment for XIM) and doing login->logout->login which avoided disk reads because of disk caches (we could so much use kernel support for this *sigh*). For the rest of the tricks, just see "ggl:KDE performance tips" (that's Google's I'm feeling lucky just in case you for some weird reason don't happen to know this is all you need to type in the Alt+F2 dialog).

I had a look at the icon loading yesterday, as that was the slide with the most question marks and there were probably most questions about it. The test was running "konqueror /", no sidebar, and it resulted in 23 icon loads (out of about 50 iconsets). Warm start: 3,5s until Konqy is idle, out of that 0,15s spent loading icons and applying effects. Bothering with 4% CPU time spent there is probably not really worth the effort. Cold start: about 11s and 1,8s or 0,8s spent loading icons (no idea why the results were almost always one of these two values ... let's use the 0,8s one). That's still only slightly more than 7%. And interestingly enough when I did "find . | xargs cat" in the icons directory before a cold start the time spent in icon loading was 0,4s. So maybe paging in the code or something like that skews the numbers for cold start. Makes me wonder again about it actually being worth bothering.

Makes me also wonder about the gtk icon cache, storing the directory/files structure of the icon images in the file, and actually also storing the images themselves there. Given that gtk somehow manages to waste 0,5M memory just on icon themes seems to be good enough a reason for gtk. The question is whether that would make an improvement for KDE. The cache is about 21M for our crystalsvg/. Loading the file into memory at once means using all that memory, but when paging it in on demand I'd expect there'd be disk seeks anyway. Storing just the directory structure in the file would make it small, but then the icon images would need to be loaded, and that'd mean reading all least some of the directories anyway.

Maybe all this icons stuff just needs a new look from a different perspective.


Do you have numbers on fontconfig slowness?
How is startup time related to number of fonts?
Is this something that could be fixed by optimizing fontconfig? If so, do you see a way to do that with current fontconfig, or are there major design flaws that would need a major redesign?

By Frank Osterfeld at Wed, 08/31/2005 - 21:51 and the [email protected] posts linked from there. The more fonts you have the slower and more memory hungry it is. There's finally some work going on to change it, but it's not really usable at the moment yet.

By Lubos Lunak at Wed, 08/31/2005 - 22:06

Hey Lubos!

6 seconds sounds too good to be true! I really wouldn't mind seeing that video. Also, you talk about slides, are they available online?

If you need hosting space for any of this, let me know.


By Andre Eisenbach at Thu, 09/01/2005 - 05:07

For the video, it can be found here:

By Frank Osterfeld at Thu, 09/01/2005 - 06:21

And the slides are at

By Lubos Lunak at Mon, 09/05/2005 - 14:23

The trick with the Gtk icon cache is that the file is mmaped, and it contains the decoded image data, so each app doesn't have to decode the data and store a copy of the image. Instead every app shares the memory for all icons.

By alexl at Thu, 09/01/2005 - 07:47

Not really true. Or, actually, true, but the conclusions are not. The decoded image data in the gtk icon cache is not the final format of the data, so although it's a shared memory, it's additional memory.

By Lubos Lunak at Mon, 09/05/2005 - 14:26

That is false. The decoded image data in the file is in a format that can be immediately used for a GdkPixbuf, and that is what happens. You are free to believe whatever you will of course, but images *are* shared.

By alexl at Wed, 09/07/2005 - 17:15

But that's the _input_ format for GdkPixbuf. It's not the _final_ format that's used for the actual displaying of the image. The shared data is just some temporary data that will still need to be sent to the X server and that's not needed for the actual displaying. Unless Gtk does the XImage->Pixmap conversion everytime, in which case I no longer wonder about those 0,5M.

By Lubos Lunak at Fri, 09/09/2005 - 09:44