Killing KInit With Fire
Open, Needs TriagePublic

Description

See KInit - Current state and benchmarks thread started by @davidedmundson on kde-frameworks-devel.

The current situation is:

  • the performance gain is way less impressive than it used to be
  • the tests on slow hardware still give a little gain, but far from impressive either
  • alberts really old machine seems to gain a lot, why? this needs to be investigated. is it maybe measuring a debug build that does a lot more disk-io due to larger library sizes?
  • most applications don't do the necessary work to benefit from kdeinit

    almost no code path nowadays really use it (as far as startup is concerned, it goes through kdeinit only from the file explorer and you have to try to open a file for which the corresponding application did the work, chances it happens are very low)
  • no one complained that things got slow

Based on the above, the conclusion is: let's phase it out and move it to unmaintained. If that was to become a real problem in the future we could team up with an existing solution or resurrect it. Nothing indicates this is currently needed to go through an effort to generalize it again.

Alternatives or related tools

https://github.com/facebookincubator/BOLT

-Wl,--as-needed but disable that for KCrash and ICU and potentially others.

Actually profile startup time to investigate which libs are triggering large overhead at _dl_start time

mwolff created this task.Nov 23 2019, 11:45 AM
nicolasfella moved this task from Backlog to Metatasks on the KF6 board.Nov 25 2019, 9:27 PM
nicolasfella moved this task from Metatasks to In Progress on the KF6 board.Nov 26 2019, 5:50 PM

almost no code path nowadays really use it (as far as startup is concerned, it goes through kdeinit only from the file explorer and you have to try to open a file for which the corresponding application did the work, chances it happens are very low)

Just to super pedantically clarify that.

As far as plasma startup is concerned it goes through kdeinit only for kded and kcminit_startup, but not the rest of autostart with plasmashell, ksmserver etc.

As far as later application launching is concerned, it goes through kdeinit only from the file explorer and you have to try to open a file for which the corresponding application did the work, chances it happens are very low.

alberts really old machine seems to gain a lot, why? this needs to be investigated. is it maybe measuring a debug build that does a lot more disk-io due to larger library sizes?

I did have a look via ssh. They weren't debug builds. Supposedly they have the linker flags --as-needed already. I could reproduce the potential gains with dolphin. A lot of regular app startup time was spent dealing with fonts, which is one area kdeinit supposedly helps with. Though I was unable to confirm that this was where kdeinit saved time.

This raises a question. what do we want to do with KToolInvocation?

KToolinvocation effectively does two tasks:

  • Act as way of starting processes. Rather like KRun, but very explicitly tied to klauncher and at a lower tier.
  • Helper methods for launching emails, browsers and terminals that follow the user preferences.

It's not especially well used.
Generally KRun is better at the first task. It's more portable, it does StartupIDs property, and can do arguments and files better.

The helper methods I think aren't too bad. IMHO we should move them to the pending new KRun so there's one app-launching implementation.

Found something interesting:

I removed kdeinit5_startup from startplasma.

In theory still going into a kinit path should call ensureKdeInit running and still work.

In practice when it is auto-activated something is wrong and klauncher doesn't work properly. I haven't fully investigated what, I ended up having to put the kdeinit5 startup back into startplasma again.

That implies kinit there's always been a problem for code that uses KToolInvocation on Gnome unnoticed for ages :/

Subtasks, we want to remove kinit from the few places that do use it correctly.

Excluding ioslaves for now that's:
https://lxr.kde.org/ident?_i=kdemain&_remember=1