I use e4rat with KDE and I can tell you, that it speeds up the start of kde very very good! Without e4rat the start of KDE is slow as hell and with e4rat it is a lot faster (but with every KDE update I hope it gets faster).

Best regards!

Thanks, but I think this already came up. As I understand it e4rat is specific to ext4 and btrfs, and potentially hazardous to boot, so I don't consider it a very good option for speeding up KDE startup times. Maybe it will be a better option in the future, when ext4 and btrfs are more widely used... Dunno.

Okay, I have to ask: does anyone here have KDE starting in under ten seconds? On a machine with a standard hard drive, and without cheap hacks like e4rat? I just have trouble believing that the developers haven't noticed how slow the start time is.

Seriously? Nobody?

Kind of amazing, considering KDE 3 was faster to start than Xfce. How do people not notice things like this?

Note that the startup performance of KDE will be heavily dependent on the number of Applets you have in use, the type of Wallpaper you use, as well as the number of applications you have set to run on start / being resumed from the previous session.

It also depends on how much the disk is needed. The KDE startup procedure is very disk intensive.

bcooksley wrote:Note that the startup performance of KDE will be heavily dependent on the number of Applets you have in use,

Only the default set.

the type of Wallpaper you use,

Usually PNG image, but switching to a gradient or solid color makes no difference.

as well as the number of applications you have set to run on start / being resumed from the previous session.

None whatsoever - I use an empty session. Starting KDE still takes longer than the rest of the boot process.

It also depends on how much the disk is needed. The KDE startup procedure is very disk intensive.

Three questions then -

1. Why is it so disk intensive? KDE3 was as functional and did not require anywhere near as much disk access on startup.

2. What could the developers do to reduce disk usage? Could binaries perhaps be compiled statically by default to reduce external fragmentation? Or maybe prelinked by default? Those are kind of ugly solutions... Even so.

3. What can I do to reduce the disk usage? Keeping in mind that prelink is broken on Slackware and e4rat could potentially destroy all my data...

Thanks for answering, anyway.

As far as I know, no one really knows why the startup procedure is so disk intensive. Diagnosing this would likely be very helpful in speeding up the KDE 4 startup procedure.

It gets even better... On KDE 4.3.4 (on Scientific Linux 6.1) startup time is 12 seconds from a cold boot, and 7 seconds for restarting KDE - same as Gnome basically. The behavior I see in later versions of KDE is clearly a regression.

Edit: Wait a minute, Scientific Linux uses prelink. That's probably why KDE starts so much faster.

Prelinking would have quite an impact I imagine, as large parts of KDE are built up of many plugins and use many libraries.

Plasma for instance is virtually entirely made up of plugins (the panels, wallpapers, applets, etc).
KRunner is very similar too (All runners are plugins as well). Many other KDE applications are also built entirely around plugins, or use them for a large part of their functionality.

Okay, this is weird. iotop says kdeinit is not reading to the disk or swapping, it is almost exclusively writing, and writing rather a lot. What do you think it might be doing?

Edit: is there a way I can find what processes are writing to what files? lsof maybe? Can it be told to show only files being written to?

Edit again: tried lsof, couldn't see anything abnormal. This is very strange.

My guess is that it may be rebuilding the Sycoca, which is a KDE wide cache of information used to build the menu used by Kickoff, find plugins and other performance crucial information (including file associations).

If so, the file being written to will be /var/tmp/kdecache-$USER/ksycoca4 - but this file shouldn't be too large (it is only 1.9mb here) and shouldn't be rewritten unless changes are found.

Another thing it could be writing to is ~/.xsession-errors - especially if debug output is enabled. Debug output can be toggled using KDebugDialog.

It should be noted that many KDE applications can appear to be "kdeinit4" as it forks itself off to launch many applications as part of a preloading optimisation used by KDE 4.

The ksyscoca cache wasn't on the list of open files...

.xsession-errors was, but there wasn't a whole lot in it. Turning off debug output did absolutely nothing to improve startup performance, even though it seemed to reduce the size of the error log.

Is it maybe possible that something is getting read/written in extremely small chunks, resulting in significant slowdown? Like how dd is slow if you set bs very low?

That could very well be the case. I am not aware of any other files which should be regenerated on KDE startup however.

Another thing it could be is the icon cache, located at /var/tmp/kdecache-$USER/icon-cache.kcache
Plasma's SVG cache could also be a suspect, located at /var/tmp/kdecache-$USER/plasma_theme_default.kcache

I just noticed something weird: startup with the "SimpleSmall" splash screen takes a shorter time than startup with no splash screen at all.

Maybe ksplash is being run even when I'm using no splash screen. Let me see if 'chmod -x'ing it makes a difference (or just keeps KDE from starting).

Edit: well that doesn't help much...

BTW there's something else I've noticed: KDE's main menu, if open during startup, will close itself every time a new system tray icon loads. This makes the desktop unusable until all the tray icons have loaded. Is this a bug or a feature? If it's a feature, is there any way to disable it?

Interesting. It could be caused by the loading of icons used by the KSplash theme (which if written one by one, especially with the fading could cause significant I/O), or the writing of the background images.

With ksplashsimple, I think a seperate executable "ksplashsimple" is used instead though...