KDE Can Now Start A Heck Of A Lot Faster

[carewolf]

But the problem is, why does KDE start slower than say Gnome in the first place? It's a welcome addition but why was KDE plagued by this issue for these many years in the first place?

It doesn't. Load a proper KDE distribution and it starts in less than 1 second, but of course if you start a GNOME distro and spend 20 second loading GNOME and finally GDM, then it is going to take some time swapping that shit out before you can spend a second loading KDE.

[balouba]

I disgress, kde4 takes several seconds to load (regardless of having a fresh profile or not). This started to be bad around some 4.x revision a few month ago, in fact.
gnome takes ~1s here (oh and yeah, as you might expect, i run this on couple of raid0 high speed ssd and theres enough ram that swap is never ever hit)

[GreatEmerald]

They should rename it ksession (replacing ksmserver) to be consistent with the naming convention for other KDE components.

Nah, rather to "csession". KDE got tired with everything starting with the letter K. Hence Calligra, and KDE release codenames have started with C as well (Cnuth, Cartoffel, Cilense, Cold). Although lately they haven't been using codenames at all.

[curaga]

Still too slow!

Yep. If a desktop/wm takes longer than 100ms to start, it's crap, to put it bluntly.

[TheBlackCat]

But the problem is, why does KDE start slower than say Gnome in the first place? It's a welcome addition but why was KDE plagued by this issue for these many years in the first place?

I think there is a combination of factors:

1. As others have said, "if it ain't broke, don't fix it". Since the startup process is so critical devs were afraid to introduce regressions.

2. I think it partly has to do with how KDE is structured. It is fairly monolithic, so a lot of the libraries and resources are loaded right off the bat, even if they aren't needed at the time. This improves access time later, but slows down the startup process. They could do this in the background, but that is more complicated and risky, and it is difficult with how the libraries are structured internally. Hopefully more can be done along these lines with frameworks 5

3. Similarly, a lot of DEs use a trick where they show you something, but it isn't fully usable yet because stuff is still being loaded in the background. KDE does this a lot less, being able to mostly use your desktop and applications as soon as it appears (windows is particularly notorious for this, try clicking on the start menu as soon as it is visible). Still, user-visible portions can be prioritized over unnecessary things, and parts of the artwork can be loaded more an-demand as well perhaps.

4. There seemed to be more pressing issue to resolve. Frankly, I am surprised we haven't gotten any "why are you wasting time on the startup process when there are all these bugs" comments yet.

None of these are fundamental issues. 2 is somewhat limited until frameworks 5 makes things more modular, but there is still a lot of room for improvement now, and none of the frameworks 5 related changes can be done without some other more basic restructuring. Further, I am sure there are limits as to what this sort of approach can do while kdelibs is frozen. So I doubt we will see this merged into mainline before frameworks 5.

[ChrisXY]

It doesn't. Load a proper KDE distribution and it starts in less than 1 second, but of course if you start a GNOME distro and spend 20 second loading GNOME and finally GDM, then it is going to take some time swapping that shit out before you can spend a second loading KDE.

I can't confirm that. On Archlinux on a SSD I get like ~2 seconds system startup time and about 5-10 seconds kde start time.

Perhaps it's because my akonadi database has 150 megabyte of junk and I have not found out where it stores the backup copy of that database so I can delete it properly.

[Awesomeness]

well there actually has been other work see Aaron's comment here http://aseigo.blogspot.com/2013/01/plasma-active-4.html on startactive which is a systemd based solution, so there has been playing around with that otherwise but yeah...

Read again. They are replacing startactive (which is a trimmed down version of the current startkde script) with a systemd-based solution. However sessionk does not depend on systemd which might be an advantage for Kubuntu, Debian, and FreeBSD users but OTOH is an additional piece of software to maintain for KDE.
I don't care which solution I get as long as it works.

[ChrisXY]

You can test it out, but not everything works. Some observations:

1. It really starts kde much, much more quickly than startkde
2. I don't get tooltips from things in the system tray
3. I can't change keyboard layouts
4. It deleted my desktop background image settings on the first start, even for the regular kde session
5. It uses a different icon set for the tray icons than I have set in kde settings
6. The font uses colored antialiasing. I noticed because it bothers me on most monitors I see it on. So probably the font settings are not correctly read or set
7. The kde screen lock doesn't work
8. Doesn't seem to load the kscreen service properly on starting

Promising start, but not really useful as of yet.

[przemoli]

1) KDE startup just work. :P
2) KDE startup relay on sleep(4)
3) sessionk start base kde in 5 seconds on NON-SSD hardware!

[halfmanhalfamazing]

Martin Graesslin's bootup contribution

A lot of work has been put into making KDE log in faster, from all portions of the community it seems.

http://blog.martin-graesslin.com/blog/2012/04/improving-kwin-startup-performance/

I can speak to this first hand. Moving from KDE 4.8.x to the 4.9 series was night and day in terms of boot up times. I'm glad that there's still continued work going into this effort.