Startup is one of the rougher aspects of the Plasma experience and therefore something we've put some time into fixing
Why is startup slow?
The primary reason for Plasma startup being slow is simply that it does a lot of things, including:
- Session restore
- Config migration
- Setting keyboard layouts
- Most esoterically, making sure your colour scheme gets synced to the xrdb database, so that loading xfig or dia or any other pre-Qt/GTK1 application still has the correct colours in your Plasma session
Too many to list. This means it's easily a whole second or more before we even start loading plasmashell, one of the more time consuming parts of startup.
This slow load gets exaggerated by us not removing the splash screen till everything is actually properly loaded.
However, it's still an area we can improve.
About startup
Startup consists of mulitple components invoked at 3 different levels.
- Kcminit
Config modules (kcms) typically update a system when the user applies the settings, however as we need to restore settings there is an optional hook called on startup for various modules. - KDE Daemons (kded)
Evolving from the more static nature above may services require running in the background waiting for external events. Some modules are loaded on demand, others are loaded explicitly during startup. - Autostarted applications
Meaning launcing core applications such as plasmashell/krunner as well as other applications a user might have selected; such as nextcloud or kgpg - User shell scripts
For anything else
These effectively all have their loading invoked at 3 different levels; as defined in the relevant kcminit/kded/autostart .desktop files. Note these may be shipped as core plasma, but can also include completely 3rd party items.
- Before plasmashell and other core autostart services
- Before user applications are restored / autoloaded
- After everything is restored and
A slightly more detailed version can be seen here.
Profiling
The most important part of any speed work is correctly analysing it.
systemd-bootchart is nearly perfect for this job, but it's filled with a lot of system noise.
I've made a fork of systemd-bootchart that only tracks processes owned by that user on github.
To use put the following line into:
/etc/X11/Xsession.d/00-bootchart
/usr/lib/systemd/systemd-bootchart -o /tmp -r &
To profile wayland sessions, mod the SDDM config wayland SessionCommand option.
After 20 seconds an SVG will be placed in /tmp.
An example
Below shows the boot process of my personal machine. The important part to track is when ksplashqml gets destroyed, that signifies that boot is complete. In my case this happens after 4.5 seconds.
Just some of the many fixes
There have been and continue to be lots of tiny changes around the code. Mostly using the awesome tool hotspot here are just a few of the more significant and interesting ones.
A mysterious gap of nothingness
This stupid bug was caused by ksmserver blocking whilst it completed launching phase 1 of kded daemons before it continued onto loading the next section.
Problem is plasmashell and other GUI apps loaded in phase0 first task is to register with the X session manager, ksmserver. End result is we lockup in X code till
ksmserver is done. Solved by a logic rewrite.
Multiple starts of the same daemon
This is the result of the following code in a bunch of processes all started at once.
if (! serviceExistsOnDBus) {
startExecutable(...)
}
Whilst the daemon did handle this case correctly and the false starts aborted, it's still a lot of time spend linking a process we don't want.
Solution in this case was to port to DBus activation which is designed for this exact case.
Shortcuts writing on load
When profiling kglobalaccel5 we found it spent a lot of time writing entries on boot, which is a clear sign of something being wrong. The cause was quite complex. Powerdevil would report that the user visible name of the executable (kded) was "Powerdevil". KScreen would load and report that the username of the executable (also kded) was "kded" this would cause the shortcut daemon to think locales had changed and forcibly reload and save everything.
Summary
Startup is an area that is being improved and we have tonnes of ideas left of things to do, but because it's dealing with unpredictable 3rd parties it's an area which requires 90% reading and 10% coding.
If you do have an excessively long boot time, please do try creating a boot chart as above, it will really help start to narrow down where we have problem. I hope to see some detailed reports on bugzilla soon.