KInit - Current state and benchmarks

[Volker Krause]

Thanks for the very interesting and useful research!

On Monday, 17 June 2019 11:56:15 CEST David Edmundson wrote:
> From API.kde.org:
> >Using kdeinit to launch KDE applications makes starting a typical KDE
> >applications 2.5 times faster (100ms instead of 250ms on a P-III 500)
> Certainly sounds like a good thing.
> 
> ===The current State===
> 
> ==Plasma==
> * Apps launched from the plasma menu skip klauncher and therefore
> kinit. This was done due to the API for KRun blocking somewhere
> (Though I don't remember details)
> 
> This seems like something easily fixable if we tried.
> 
> * Processes launched on bootup (with the exception of kcminit,
> ksmserver and kded5) skip kinit. This was due to a deadlock in
> klauncher and ksmserver at the time when apps autostart moved from
> frameworks.
> 
> This deadlock is since resolved in my ksmserver splitting branches.
> 
> * But Plasma apps launched from the desktop do go through klauncher
> (and therefore kinit)! So we're not even consistent.
> 
> ==Apps==
> * The number of applications linking kinit properly under KF5 is in an
> equally sorry state.
> Dolphin does, but even core applications like Okular and Kate don't.
> 
> See
> $ find -name 'CMakeLists.txt' -print0 | xargs -0 grep
> 'kf5_add_kdeinit_executable'
> for a local list.
> 
> * It's also incompatible with flatpak/snaps/appimage, which is a rising
> trend

That might be solvable with making that a build option (and having a 
corresponding CMake macro to automate that) I guess?

> ==Other==
> Kinit is still also used for spawning KIO slaves.
> 
> ===Is it still useful?===
> We're not using it properly and we need to do something. Either fix it
> or start to phase it out officially.
> 
> Since the time of writing kinit Qt has changed a lot. linking has
> changed a bit. CPUs have changed a lot and Hard Disks have changed a
> lot.
> 
> So I wrote a benchmark tool to see if the initial speed boost claim is
> relevant: kde:scratch/davidedmundson/inittimer
> 
> My test does the following:
>  - creates a dummy (headless) wayland server
>  - spawns an app using either QProcess or sending a DBus message to
> KLauncher - times how long it takes for the first window to appear, timing
> the more important real world metric and one that includes all the
> factors.
> 
> Results:
> (Showing the median out of 5 runs on a mid range SSD desktop)
> 
> Dolphin QProcess: 348
> Dolphin Kinit: 332
> 
> KCalc   QProcess:  242
> KCalc   KInit: 232
> 
> Plasmoidviewer (patched) QProces: 622
> Plasmoidviewer (patched) KInit: 591
> 
> KWrite  QProcess: 391
> KWrite  Kinit: 390
> (unsurprisingly similar as kwrite does not have a kdeinit exec, I
> included it as it shows the others aren't false positives)

Which libraries are covered by this mechanism nowadays? The impact is of 
course bigger the more of the dependencies of the applications are already 
loaded. When this was developed this was a small amount of relatively large Qt 
and kdelibs libraries. I'm wondering if the current subset is still relevant, 
both from Qt (e.g. thinking about QML/Qt Quick) and KF5?

> ===What about memory?===
> 
> Good question. It needs a similar investigation by someone who
> understands memory...

Regarding memory impact, I think a good first approximation is the sum of the 
sizes of the .data.rel.ro sections in all covered libraries. Those are 
allocated, written to once (for relocating information), and can then be 
shared. There can be more, but this covers vtables, QMetaObject data, etc, ie. 
stuff we tend to have a lot of. Order of magnitude is QtCore 40kB, QtGui 50kB, 
QtQml 100kB, QtDeclarative 140kB, QtWidgets 170kB. I vaguely recall this to be 
much larger in some (binary) graphics drivers, not sure if that's still the 
case though.

Hm, something that might also be worth looking into is if we can load kinit 
with the equivalent of RTLD_NOW in dlopen, so that all .got section entries 
are resolved already (making those sections fully shareable as well), and more 
importantly avoiding the symbol lookup to be done on-demand multiple times. 
Not sure if that's worth it on desktop, but for Plasma Mobile this could be 
relevant. That would probably be also my general conclusion for the entire 
topic.

Regards,
Volker

> ===Conclusion===
> 
> My test implies there /is/ a genuine saving with kinit !
> However it's far from the claimed 2.5 times faster, it is less than
> 1.1 times faster. Saving up to 30ms.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20190617/c7851d9a/attachment.sig>