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
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 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 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 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
On Sat, 22 Jun 2019 at 11:21, David Edmundson wrote: > > Benchmarks of dolphin on a low end ARM laptop: > Dolphin via QProcess: 1233ms > Dolphin via Kinit: 1144ms > > again a consistent saving in the order of ~7% > > Initially I had wanted to scrap it, I'm now very conflicted. > > I'll try to port all of plasma services to use it properly again and > see what difference that makes across a broad context over a wider > range of services. > > David Hi David, There is also one more thing we might want to take into account: Kinit mostly breaks ASLR since all libraries will have libc, QtBase, etc mapped at the same address if we do fork() without execve(). This makes code reuse attacks a bit easier since the attacker can reuse the guessed addresses for all base libraries. Only the executable and any libraries loaded by the executable will have randomized addressed. However, in my opinion all probabilistic vulnerability mitigation schemes such as ASLR are not particularly useful since they just make it more difficult for an attacker rather than actually preventing the attack. Moreover, it has been shown that ASLR can be broken due to MMU side-channels (even from JavaScript running in a browser sandbox!) [1] or if you have a fork()ing server (which is similar to the kinit case)[2]. Upcoming CPUs will have more useful features to partially enforce control flow integrity (Intel Control-flow Enforcement Technology (CET) or ARM Branch Target Indicators (BTI)) which should be more effective than ASLR. Personally, I think it makes sense to keep kinit if it speeds up start-up by 7% even if it (mostly) breaks ASLR since ASLR is already pretty much broken. Also we have been doing this for years and I don't think there has been a CVE because of kinit not randomizing some library locations. I am currently working on CHERI [3], an ISA extension that adds 128-bit capabilities (essentially pointers with bounds and permissions) to the MIPS (and RISC-V) ISAs. We currently run everything on a 100Mhz FPGA so I'm sure the start-up time would be quite noticeable there. I have not yet managed to get kinit to compile but we do have QtBase and QtWebkit working. It shouldn't be too hard to compile kinit and run the measurements but I doubt I will have time to do that in the next month or two. In the past few years I've done quite a lot of work with the FreeBSD runtime linker. Based on my current measurements of relocation processing in the runtime linker, it can take a lot of time to resolve all symbols (especially if lazy binding is disabled by linking with -z now) and to process all relocations. I believe LD_BIND_NOW/-z now is becoming the default in some distributions since it allows mapping the GOT read-only after relocation processing and therefore slightly reduces the attack surface. Kinit allows us to skip those steps for some of the libraries so it should always be a noticeable performance win. Alex [1] https://www.vusec.net/projects/anc/ [2] www.scs.stanford.edu/brop/bittau-brop.pdf [3] http://chericpu.com
Re: KInit - Current state and benchmarks
Benchmarks of dolphin on a low end ARM laptop: Dolphin via QProcess: 1233ms Dolphin via Kinit: 1144ms again a consistent saving in the order of ~7% Initially I had wanted to scrap it, I'm now very conflicted. I'll try to port all of plasma services to use it properly again and see what difference that makes across a broad context over a wider range of services. David
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
On Wed, 19 Jun 2019, 16:39 Aleix Pol, wrote: > 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. > kde:scratch/davidedmundson/inittimer > Aleix >
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
> Seems like this would need some refocusing if we want to keep it? Definitely. We've essentially broken all of it right now. My goal for the research and this thread is to try and get a definitive kde-wide answer to "if we want to keep it" so I know where to put work in.
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 Monday, 17 June 2019 21:34:38 CEST David Edmundson wrote: > > 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? > > From what I can tell: > > implicitly linked to kdeinit: > QtBase > QtGui > Crash > I18n > ConfigCore > WindowSystem > > explicitly added at runtime: > KIOCore > Parts > Plasma > > and all the dependencies thereof. > Note libplasma doesn't link QML/Qtquick ah, I missed the runtime part when searching for this. So that covers a lot of KF5 (via the extensive dependencies of Parts) I think, as well as QtWidgets. Newer Kirigami-based applications that are more interesting for Plasma Mobile would likely benefit much less from this compared to XMLGUI desktop applications (which are less relevant on resource-constraint mobile/embedded platforms). And Plasma itself is also not be optimally served by not covering QtQuick I guess. Seems like this would need some refocusing if we want to keep it? Regards, Volker 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
> 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? > >From what I can tell: implicitly linked to kdeinit: QtBase QtGui Crash I18n ConfigCore WindowSystem explicitly added at runtime: KIOCore Parts Plasma and all the dependencies thereof. Note libplasma doesn't link QML/Qtquick
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
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
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.
