Faster Startup
Open, Needs TriagePublic

Description

Improving start up time ideas:

Most should be profiled first before committing heavily to huge ports. There's a chance I'm talking rubbish

  • start kwin and plasmashell (and the rest of autophase0) in parallel with ksmserver

(d_ed started this already, see T9779, the biggest challenge is properly syncing the SESSION_MANAGER properly)

  • redo the way plasma signals to ksplash. We don't need to wait for panels, we do want to wait for the wallpaper. I'd like to see some sort of ref counted blocker object, and we signal when that's gone completely.
  • get rid of panel waiting timer on first run? - ideally requires knowledge that kscreen has finished
  • Make solid not suck with a billion blocking calls

(Kai has started this D19677)

  • Removing blocking calls in plasma-nm
  • kpackage as a qt resource (that Marco started)
  • Proper use of KPluginFactory - one plugin with a factory for loading N plugins means we only link once. I think this will give noticable speed boosts.

Similarly we only need one binary lib for loading multiple QML plugins.

  • System service to precache all used files? Gather a big list with strace and then open + fadvise them in a service?
  • KConfig loading in a thread? Could be done whilst we do other slow startup tasks
  • Porting more things to QtQuickcontrols2 to reduce the sheer quantity of QML code involved
  • Delay (or at least optimize and/or profile why they're heavy) starting up services that aren't critical for the session: baloo, krunner.
  • Plasma::SvgPrivate::elementRect is surprisingly slow and called a lot
davidedmundson renamed this task from Startup to Faster Startup.
davidedmundson updated the task description. (Show Details)
mart added a subscriber: mart.EditedMay 21 2019, 1:42 PM
  • kpackage as a qt resource (that Marco started):

That was blocked after fvogt complained about it saying he's sure it would have the exact opposite effect (slowing startup time and increasing memory usage).
Now I don't know what would really be the difference, on the tests i did i failed to find any appreciable difference in any direction neither in startup time (with aleix startup tracking class) nor in memory usage, I don't know how to do really precise measurements, but seems overall pretty non influent

mart updated the task description. (Show Details)May 21 2019, 1:49 PM
apol updated the task description. (Show Details)May 22 2019, 6:43 PM
apol added a subscriber: apol.May 23 2019, 12:28 AM

Taking a closer look I've found out there's a new thing. Now Qt stores its plugin information into cbor instead of the former non-standard binary json format.
At the moment, this is taking ~5% of the very first plasmashell boot time. It could make sense to sort it out. Needs to be done at Qt level though and possibly including doing a QJsonDocument to QCborValue.

davidedmundson added a comment.EditedMay 23 2019, 12:07 PM

Now Qt stores its plugin information into cbor instead of the former non-standard binary json format.

That's a good find
This is a combo of two things to investigate.

  1. can we load plugin data faster
  2. are we probing all the right plugins only a sensible number of times - there shouldn't be many cases where we should be iterating over everything
broulik updated the task description. (Show Details)May 28 2019, 2:03 PM
apol added a comment.May 30 2019, 4:23 PM

Another thing to look into is that the QtNetwork Bearer interface has a full networkmanager interface that is always blocking the same way that nm-qt/plasma-nm is. It could make sense to see to making that one async and we'd accelerate not only plasma boot but many applications.

apol added a comment.Jul 4 2019, 2:47 PM
  • Solid udisks2 integration through the DataEngine is blocking at startup, it could be interesting to see if we can do it differently.
  • Finish fully porting plasma away from KService
ngraham moved this task from To Do to Work in Progress on the Plasma board.Fri, Sep 27, 3:40 PM

Are we considering this done, or is there more to do here?

There's always more work to be done.