Plasma Startup

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.


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:

/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) {

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.


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.

23 thoughts on “Plasma Startup”

  1. Great work 🙂
    Dunno if that’s interesting to you : I noticed the Plasma startup is increased severals folds here when enabling the “Force Compositing Pipeline” option in the Nvidia drivers.

  2. Comparing Windows startup with KDE is a problem. I know that Windows will show you the desktop before it’s done loading. This slows down what ever it is you are trying to do. Add to it automatic updates and virus control and it’s pretty slow going for awhile. I’ve recently read that Win10 has a fast boot procedure, that is esentially just waking up from hibernation.

    On the other hand when KDE shows you the desktop it is ready to go.

    1. I love that about Plasma or Linux in general. As soon as desktop shows up, it’s ready to work without lags, while Windows takes veeeeery long to load all those additional services or application and of course the disk is working like crazy because of all of this spying (connection to ms servers and sending info on boot up, checking updates and whatnot).
      Plasma does boots slower then other DEs but is still many, many times quicker then Windows (when comparing normal boots, Windows fast startup is a different matter and it cannot be used on dual boots anyway).

  3. For me, in Manjaro KDE, it takes 20 seconds, from complete shut down, to working state.
    Is’t MORE than decent.

  4. I’d just like to point out that on all my machines, the ending of ksplashqml leaves me with a black screen on which eventually wallpapers and panels appear (usually about 5-10 seconds). “…when ksplashqml gets destroyed, that signifies that boot is complete…” in no way means that the desktop is ready for use. Yes, plasmashell is running, but the delayed load of all the QML stuff takes a really long time.

  5. Terribly !funny question/advise:
    My Tumbleweed with a CPU Dual Core E6600 at 3.06GHz, with 8Gb of Ram takes about 2min and 15sec to get ready.
    Do you think this is “normal”?

    1. No, it should take roughtly 5 seconds

      In fact ksplash will time out after 30…

      which means you’re probably hitting bug between sddm and startkde.
      I’ve seen that once with a bug in some debian packaging that made blocking calls to a notification server that didn’t exist.

      In any case..get yourself a bootchart as above and find out!

      1. i forgot to mention that this is from the moment i hit the power button :S (sorry!)

        i still think it’s a lot of time… but maybe i’m wrong about that

  6. Hi David!

    Thanks for the writing about this. My plasma startup feels quite slow and this post made me finally start doing something about it.
    * I have my bootchart. Is there a central place where startup time issue is being tracked or should I just create a new bug report?
    * You mentioned that the splash screen is only removed after everything is loaded. However for me, the plasma panels and wallpaper, for instance, are still missing when the splash screen goes away. Is that expected, or a bug?


    1. bug report probably is easiest, then from there we’ll see which component is most rubbish and bisect in there.

      >* You mentioned that the splash screen is only removed after everything
      is loaded. However for me, the plasma panels and wallpaper, for
      instance, are still missing when the splash screen goes away. Is that
      expected, or a bug?

      Yes, but that’s kinda known. Our concept of “ready” is a bit premature.

    1. >Wouldn’t it make KDE’s startup faster

      Not really. You can’t do the same things in the same order and get faster results.
      You can’t change the order without breaking things. I don’t think it’s related to the problem.

      In particular the major thing is if you make plasmashell not launched by ksmserver then it doesn’t have the correct X_SESSION_MANAGER env..which means anything it spawns also won’t have it..

      It does have other benefits though.

  7. On my Alienware 17 R3 latpop with SSD M2 Manjaro KDE install, from Grub too loaded desktop with fully functional network, it takes about 12-16s so I can’t complain. I even have lot of additional services and applications starting with the system so that’s not a lightweight install.

    On my older Lenovo 780G laptop with HDD, it takes much longer (over a minute) but I don’t expect that much from laptop HDD. However Plasma does start much slower then other DEs, visibly slower. I just accepted it since it’s so much better then alternatives, but I don’t mind to trim this process down so I’m happy with the initiative. I just wanted to tell that boot up process is not always that bad in all cases.

  8. Good to see some interest in this part of the plasma stack. Thank you.

    splash disappearing only when session is completely loaded is a sane
    behavior IMHO. In the pre-SSD era I always got frustrated by these
    environments (ie windows, gnome 2) which dropped you on the desktop but
    you were unable to do anything as it was still loading. OK you could
    enjoy your Matrix wallpaper but then what? 🙂

    yeah, I prefer to start using my system when it is actually ready.
    Nevertheless, waiting should not be the case anymore, Plasma should
    match the others and provide an “almost” instant access when leaving the

    best regards!

  9. I noticed after the most recent kernel update that going from login to the loading of the desktop takes at least a minute, where it used to take 20-30s. For a newbie it’s quite difficult to diagnose & fix.

Leave a Reply

Your email address will not be published. Required fields are marked *