Page MenuHome GnuPG

Kleopatra, GPG: AboutData ctor on Windows takes too long
Open, NormalPublic

Description

With the code:

qCDebug(KLEOPATRA_LOG) << "Startup timing:" << timer.elapsed() << "ms elapsed: Service created";

AboutData aboutData;
KAboutData::setApplicationData(aboutData);
/* This is more expensive as it sounds as it might run a verification
 * on a signed Version file and initializes the whole GpgME::Engine. */
qCDebug(KLEOPATRA_LOG) << "Startup timing:" << timer.elapsed() << "ms elapsed: About data created";

I see:

[13096] org.kde.pim.kleopatra: Startup timing: 284 ms elapsed: Service created
[13096] org.kde.pim.libkleo: No signed VERSION file found.
[13096] org.kde.pim.libkleo: Parsed 2.2.41 as:  2 . 2 . 41 .
[13096] org.kde.pim.libkleo: Running gpgconf --show-versions ...
[13096] org.kde.pim.libkleo: Running gpgconf --show-versions timed out after 1 second.
[13096] QProcess: Destroyed while process ("C:\\Gpg4win\\bin\\..\\..\\GnuPG\\bin\\gpgconf.exe") is still running.
[13096] org.kde.pim.kleopatra: Startup timing: 1815 ms elapsed: About data created

So what we see here is that gpgconf --show-versions takes more then a second and is even timed out. Afaik this is because it in turn calls all the processes which then do their initialization. Kleopatra caches this later but this is the first call.

On the Kleopatra side I think the solution will be to put the very important parts of KAboutData like Application Name and Organization which is used for config files and just put "Loading..." in the information of the branding texts. I guess they will never be opened before they are checked. Then we can put that into a background thread. As in the case of a signed version file the about data init would also do a gpgv call with a version validation. The timing shown above is without a signed VERSION file.

On the gpgconf side. I don't really know, its kind of a design issue that gpgconf starts each process to query information about the process so that all gpgconf calls take a while. We should try to delay this as long as possible and show UI before this.

This is a bit related to T6331 where a problem is that the KUniqueService is initialized too late on Windows to avoid parallel calls.

Event Timeline

aheinecke created this task.
aheinecke lowered the priority of this task from High to Normal.Jan 11 2023, 12:10 PM

by moving the KUniqueService before this and with the change b58cf129f the priority is reduced. It will still take 200ms so we might want to do something about this but it is not prio high as the 200ms are only on first run.

I would like to take this on myself by creating a gpgversioninfo class which will have signal / slot based API for both the SWDB Query and the version checks, both currently delay the startup too much.

aheinecke mentioned this in Unknown Object (Event).Aug 28 2023, 7:20 AM

I have a bad patch for this. D567 But I think we need a better solution that works without libkleo and could live in KCoreAddons as a change to KAboutData so that we can reuse it better for T6594

aheinecke mentioned this in Unknown Object (Event).Mon, Sep 25, 8:52 AM