KInit - Current state and benchmarks
>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 ==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) ===What about memory?=== Good question. It needs a similar investigation by someone who understands memory... ===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.
Re: KInit - Current state and benchmarks
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. signature.asc Description: This is a digitally signed message part.
Re: KInit - Current state and benchmarks
El dilluns, 17 de juny de 2019, a les 11:56:15 CEST, David Edmundson va escriure: > Results: > (Showing the median out of 5 runs on a mid range SSD desktop) Are we sure it's fair to assume people have SSD? our of the 4 laptops i own, only 2 have SSD. Do you think it's worth me trying in one of the two that don't have SSD? Cheers, Albert
Re: KInit - Current state and benchmarks
> Are we sure it's fair to assume people have SSD? our of the 4 laptops i own, > only 2 have SSD. It's at least safe to assume it's the trend moving forward. > Do you think it's worth me trying in one of the two that don't have SSD? More data is normally a good thing. If you or anyone else wants to collect stats: >From my git link above, it's as simple as running the normal ; cmake; make ; ./kinittest -median 5
Re: KInit - Current state and benchmarks
On Tue, Jun 18, 2019 at 12:05 PM David Edmundson wrote: > > > Are we sure it's fair to assume people have SSD? our of the 4 laptops i > > own, only 2 have SSD. > > It's at least safe to assume it's the trend moving forward. > > > Do you think it's worth me trying in one of the two that don't have SSD? > > More data is normally a good thing. If you or anyone else wants to > collect stats: > From my git link above, it's as simple as running the normal ; cmake; > make ; ./kinittest -median 5 I don't see a git link above. Aleix
Re: KInit - Current state and benchmarks
El dimarts, 18 de juny de 2019, a les 12:04:38 CEST, David Edmundson va escriure: > > Are we sure it's fair to assume people have SSD? our of the 4 laptops i > > own, only 2 have SSD. > > It's at least safe to assume it's the trend moving forward. > > > Do you think it's worth me trying in one of the two that don't have SSD? > > More data is normally a good thing. If you or anyone else wants to > collect stats: > From my git link above, it's as simple as running the normal ; cmake; > make ; ./kinittest -median 5 On my very old/very slow computer seems to make a lot of difference RESULT : DaveTest::testQProcess(): 2,625 msecs per iteration (total: 2,625, iterations: 1) RESULT : DaveTest::testKInit(): 1,852 msecs per iteration (total: 1,852, iterations: 1) RESULT : DaveTest::testQProcess(): 2,390 msecs per iteration (total: 2,390, iterations: 1) RESULT : DaveTest::testKInit(): 1,846 msecs per iteration (total: 1,846, iterations: 1) So can we please keep/improve it? Cheers, Albert
Re: KInit - Current state and benchmarks
Hi, On 2019-06-17 11:56, 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. I stopped using it I guess to be consistent between all platforms shipping Kate. (beside, if you profile the Kate startup, all things are > the stuff kdeinit saves) 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 ==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) ===What about memory?=== Good question. It needs a similar investigation by someone who understands memory... ===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. my opinion: it's not worh the hassle. Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org
Re: KInit - Current state and benchmarks
On Mittwoch, 19. Juni 2019 19:57:56 CET Albert Astals Cid wrote: > El dimarts, 18 de juny de 2019, a les 12:04:38 CEST, David Edmundson va escriure: > > > Are we sure it's fair to assume people have SSD? our of the 4 laptops i > > > own, only 2 have SSD.> > > It's at least safe to assume it's the trend moving forward. > > > > > Do you think it's worth me trying in one of the two that don't have SSD? > > > > More data is normally a good thing. If you or anyone else wants to > > collect stats: > > From my git link above, it's as simple as running the normal ; cmake; > > make ; ./kinittest -median 5 > > On my very old/very slow computer seems to make a lot of difference > > RESULT : DaveTest::testQProcess(): > 2,625 msecs per iteration (total: 2,625, iterations: 1) > RESULT : DaveTest::testKInit(): > 1,852 msecs per iteration (total: 1,852, iterations: 1) > > > RESULT : DaveTest::testQProcess(): > 2,390 msecs per iteration (total: 2,390, iterations: 1) > RESULT : DaveTest::testKInit(): > 1,846 msecs per iteration (total: 1,846, iterations: 1) Hey Albert, these numbers are quite impressive but I can't quite explain those. Are you measuring maybe a full debug build without any compiler optimizations? Then the library sizes will be _much_ larger and thus trigger more page faults. If every one of those is extremely slow on that machine compared to more modern machines? May I ask how old this machine is and what the speed of the HDD is? Thanks -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
Re: KInit - Current state and benchmarks
El dissabte, 23 de novembre de 2019, a les 11:47:40 CET, Milian Wolff va escriure: > On Mittwoch, 19. Juni 2019 19:57:56 CET Albert Astals Cid wrote: > > El dimarts, 18 de juny de 2019, a les 12:04:38 CEST, David Edmundson va > escriure: > > > > Are we sure it's fair to assume people have SSD? our of the 4 laptops i > > > > own, only 2 have SSD.> > > > It's at least safe to assume it's the trend moving forward. > > > > > > > Do you think it's worth me trying in one of the two that don't have SSD? > > > > > > More data is normally a good thing. If you or anyone else wants to > > > collect stats: > > > From my git link above, it's as simple as running the normal ; cmake; > > > make ; ./kinittest -median 5 > > > > On my very old/very slow computer seems to make a lot of difference > > > > RESULT : DaveTest::testQProcess(): > > 2,625 msecs per iteration (total: 2,625, iterations: 1) > > RESULT : DaveTest::testKInit(): > > 1,852 msecs per iteration (total: 1,852, iterations: 1) > > > > > > RESULT : DaveTest::testQProcess(): > > 2,390 msecs per iteration (total: 2,390, iterations: 1) > > RESULT : DaveTest::testKInit(): > > 1,846 msecs per iteration (total: 1,846, iterations: 1) > > Hey Albert, > > these numbers are quite impressive but I can't quite explain those. Are you > measuring maybe a full debug build without any compiler optimizations? I obviously can't remember, this was *months* ago, but i just ran the test again (making sure -O3 was there and not any -g) and got a bit different results, so maybe it was. New results: * testQProcess: 2200 msec per iteration * testKInit:1700 msec per iteration Still a 20% speed improvement. > Then > the library sizes will be _much_ larger and thus trigger more page faults. If > every one of those is extremely slow on that machine compared to more modern > machines? > > May I ask how old this machine is and what the speed of the HDD is? It's a Lenovo ideapad S10-3t, around 10 years old, the HDD is slow. But it's of similar power to the Librecomputer La Frite i just got for free at LinuxAppSummit, so even this is on the slow end of things we support i think there's value on supporting it. If you're interested i can arrange you to get ssh access to the machine (the ideapad, i don't have all the KF5/Qt stack built for the LaFrite). Cheers, Albert > > Thanks > >
Re: KInit - Current state and benchmarks
On Montag, 25. November 2019 22:57:11 CET Albert Astals Cid wrote: > El dissabte, 23 de novembre de 2019, a les 11:47:40 CET, Milian Wolff va escriure: > > On Mittwoch, 19. Juni 2019 19:57:56 CET Albert Astals Cid wrote: > > > El dimarts, 18 de juny de 2019, a les 12:04:38 CEST, David Edmundson va > > > > escriure: > > > > > Are we sure it's fair to assume people have SSD? our of the 4 > > > > > laptops i > > > > > own, only 2 have SSD.> > > > > > > > > It's at least safe to assume it's the trend moving forward. > > > > > > > > > Do you think it's worth me trying in one of the two that don't have > > > > > SSD? > > > > > > > > More data is normally a good thing. If you or anyone else wants to > > > > collect stats: > > > > From my git link above, it's as simple as running the normal ; cmake; > > > > make ; ./kinittest -median 5 > > > > > > On my very old/very slow computer seems to make a lot of difference > > > > > > RESULT : DaveTest::testQProcess(): > > > 2,625 msecs per iteration (total: 2,625, iterations: 1) > > > > > > RESULT : DaveTest::testKInit(): > > > 1,852 msecs per iteration (total: 1,852, iterations: 1) > > > > > > RESULT : DaveTest::testQProcess(): > > > 2,390 msecs per iteration (total: 2,390, iterations: 1) > > > > > > RESULT : DaveTest::testKInit(): > > > 1,846 msecs per iteration (total: 1,846, iterations: 1) > > > > Hey Albert, > > > > these numbers are quite impressive but I can't quite explain those. Are > > you > > measuring maybe a full debug build without any compiler optimizations? > > I obviously can't remember, this was *months* ago, but i just ran the test > again (making sure -O3 was there and not any -g) and got a bit different > results, so maybe it was. Does this apply to your whole stack (instead of just the inittest from Dave)? > New results: > * testQProcess: 2200 msec per iteration > * testKInit:1700 msec per iteration > > Still a 20% speed improvement. > > > Then > > the library sizes will be _much_ larger and thus trigger more page faults. > > If every one of those is extremely slow on that machine compared to more > > modern machines? > > > > May I ask how old this machine is and what the speed of the HDD is? > > It's a Lenovo ideapad S10-3t, around 10 years old, the HDD is slow. But it's > of similar power to the Librecomputer La Frite i just got for free at > LinuxAppSummit, so even this is on the slow end of things we support i > think there's value on supporting it. > > If you're interested i can arrange you to get ssh access to the machine (the > ideapad, i don't have all the KF5/Qt stack built for the LaFrite). Yes, that would be interesting for me! Cheers -- Milian Wolff m...@milianw.de http://milianw.de signature.asc Description: This is a digitally signed message part.
Re: KInit - Current state and benchmarks
El dimarts, 26 de novembre de 2019, a les 8:56:54 CET, Milian Wolff va escriure: > On Montag, 25. November 2019 22:57:11 CET Albert Astals Cid wrote: > > El dissabte, 23 de novembre de 2019, a les 11:47:40 CET, Milian Wolff va > escriure: > > > On Mittwoch, 19. Juni 2019 19:57:56 CET Albert Astals Cid wrote: > > > > El dimarts, 18 de juny de 2019, a les 12:04:38 CEST, David Edmundson va > > > > > > escriure: > > > > > > Are we sure it's fair to assume people have SSD? our of the 4 > > > > > > laptops i > > > > > > own, only 2 have SSD.> > > > > > > > > > > It's at least safe to assume it's the trend moving forward. > > > > > > > > > > > Do you think it's worth me trying in one of the two that don't have > > > > > > SSD? > > > > > > > > > > More data is normally a good thing. If you or anyone else wants to > > > > > collect stats: > > > > > From my git link above, it's as simple as running the normal ; cmake; > > > > > make ; ./kinittest -median 5 > > > > > > > > On my very old/very slow computer seems to make a lot of difference > > > > > > > > RESULT : DaveTest::testQProcess(): > > > > 2,625 msecs per iteration (total: 2,625, iterations: 1) > > > > > > > > RESULT : DaveTest::testKInit(): > > > > 1,852 msecs per iteration (total: 1,852, iterations: 1) > > > > > > > > RESULT : DaveTest::testQProcess(): > > > > 2,390 msecs per iteration (total: 2,390, iterations: 1) > > > > > > > > RESULT : DaveTest::testKInit(): > > > > 1,846 msecs per iteration (total: 1,846, iterations: 1) > > > > > > Hey Albert, > > > > > > these numbers are quite impressive but I can't quite explain those. Are > > > you > > > measuring maybe a full debug build without any compiler optimizations? > > > > I obviously can't remember, this was *months* ago, but i just ran the test > > again (making sure -O3 was there and not any -g) and got a bit different > > results, so maybe it was. > > Does this apply to your whole stack (instead of just the inittest from Dave)? Yes > > > New results: > > * testQProcess: 2200 msec per iteration > > * testKInit:1700 msec per iteration > > > > Still a 20% speed improvement. > > > > > Then > > > the library sizes will be _much_ larger and thus trigger more page faults. > > > If every one of those is extremely slow on that machine compared to more > > > modern machines? > > > > > > May I ask how old this machine is and what the speed of the HDD is? > > > > It's a Lenovo ideapad S10-3t, around 10 years old, the HDD is slow. But it's > > of similar power to the Librecomputer La Frite i just got for free at > > LinuxAppSummit, so even this is on the slow end of things we support i > > think there's value on supporting it. > > > > If you're interested i can arrange you to get ssh access to the machine (the > > ideapad, i don't have all the KF5/Qt stack built for the LaFrite). > > Yes, that would be interesting for me! I sent you the details on private. Cheers, Albert > > Cheers >
Re: KInit - Current state and benchmarks
On Tue, Nov 26, 2019 at 8:57 AM Milian Wolff wrote: > > On Montag, 25. November 2019 22:57:11 CET Albert Astals Cid wrote: > > El dissabte, 23 de novembre de 2019, a les 11:47:40 CET, Milian Wolff va > escriure: > > > On Mittwoch, 19. Juni 2019 19:57:56 CET Albert Astals Cid wrote: > > > > El dimarts, 18 de juny de 2019, a les 12:04:38 CEST, David Edmundson va > > > > > > escriure: > > > > > > Are we sure it's fair to assume people have SSD? our of the 4 > > > > > > laptops i > > > > > > own, only 2 have SSD.> > > > > > > > > > > It's at least safe to assume it's the trend moving forward. > > > > > > > > > > > Do you think it's worth me trying in one of the two that don't have > > > > > > SSD? > > > > > > > > > > More data is normally a good thing. If you or anyone else wants to > > > > > collect stats: > > > > > From my git link above, it's as simple as running the normal ; cmake; > > > > > make ; ./kinittest -median 5 > > > > > > > > On my very old/very slow computer seems to make a lot of difference > > > > > > > > RESULT : DaveTest::testQProcess(): > > > > 2,625 msecs per iteration (total: 2,625, iterations: 1) > > > > > > > > RESULT : DaveTest::testKInit(): > > > > 1,852 msecs per iteration (total: 1,852, iterations: 1) > > > > > > > > RESULT : DaveTest::testQProcess(): > > > > 2,390 msecs per iteration (total: 2,390, iterations: 1) > > > > > > > > RESULT : DaveTest::testKInit(): > > > > 1,846 msecs per iteration (total: 1,846, iterations: 1) > > > > > > Hey Albert, > > > > > > these numbers are quite impressive but I can't quite explain those. Are > > > you > > > measuring maybe a full debug build without any compiler optimizations? > > > > I obviously can't remember, this was *months* ago, but i just ran the test > > again (making sure -O3 was there and not any -g) and got a bit different > > results, so maybe it was. > > Does this apply to your whole stack (instead of just the inittest from Dave)? > > > New results: > > * testQProcess: 2200 msec per iteration > > * testKInit:1700 msec per iteration > > > > Still a 20% speed improvement. > > > > > Then > > > the library sizes will be _much_ larger and thus trigger more page faults. > > > If every one of those is extremely slow on that machine compared to more > > > modern machines? > > > > > > May I ask how old this machine is and what the speed of the HDD is? > > > > It's a Lenovo ideapad S10-3t, around 10 years old, the HDD is slow. But it's > > of similar power to the Librecomputer La Frite i just got for free at > > LinuxAppSummit, so even this is on the slow end of things we support i > > think there's value on supporting it. > > > > If you're interested i can arrange you to get ssh access to the machine (the > > ideapad, i don't have all the KF5/Qt stack built for the LaFrite). > > Yes, that would be interesting for me! I have some leftover units. If that's helpful, I can arrange for you to get a unit. Aleix
