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