Page MenuHome GnuPG
Create Task
Maniphest T6260

gpgconf: Analyze timing on Windows
Closed, ResolvedPublic
Actions

Description

During startup Kleopatra needs to very early get information about GnuPG configuration before showing UI. Half a second for this seems to be excessive at first glance. Although we should probably define the Test hardware we run on. We should investigate where this takes most time and if we see possibilities to optimize this.

In Powershell:

Measure-Command {gpgconf --list-options gpg ; gpgconf --list-options gpgsm ; gpgconf --list-options gpg-agent ; gpgconf --list-options scdaemon ; gpgconf --list-options dirmngr ; gpgconf --list-options pinentry}


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 413
Ticks             : 4137875
TotalDays         : 4,78920717592593E-06
TotalHours        : 0,000114940972222222
TotalMinutes      : 0,00689645833333333
TotalSeconds      : 0,4137875
TotalMilliseconds : 413,7875

Related Objects
Search...

Event Timeline

aheinecke triaged this task as Normal priority.Oct 27 2022, 10:54 AM
aheinecke created this task.
ikloecker added a subscriber: ikloecker.Oct 27 2022, 11:42 AM

Would running the different --list-options in parallel make sense? Or would the block each other?

Alternatively, maybe a gpgconf --list-all-options (or --list-options all?) would be faster. Obviously, the listed options would have to be prefixed with the component name. Or we need a component header (like the group headers). Starting processes has been very slow on Windows so starting a single gpgconf instead of one per component could make a difference.

ikloecker added a comment.Dec 5 2022, 8:48 AM

Another idea would be a gpgconf daemon that answers all queries from its in-memory cache. Obviously, this wouldn't help with the very first start unless the daemon is started automatically on login which should probably be default behavior at least on Windows anyway. OTOH, gpgme does already cache the config so this would only have an effect when starting Kleopatra.

aheinecke closed this task as Resolved.Jan 11 2023, 2:54 PM
aheinecke claimed this task.

Currently the first call to QGpgMENewCryptoConfig::reloadConfiguration happens in the GpgSM self test. Funnily enough the selftest for gpg just returns true when the empty constructors of the cryptoconfig are called. The first component load is GpgSM.

Btw. my timings are currently done on a system with Symantec Endpoint Protection installed so they are extra slow.

I mean at some point we need to check the configuration of everything. What I want to do now would be to ensure that the first call to reloadconfiguraton should happen in the KeyCache loading which we already expect to take a while.

The idea which I have discussed with Werner is to run the selftest only at first start. This would find the installation problems the selftest checks but to do this every time is a bit unnecessary.

I am closing this issue as this was about looking into it more / analyzing this and now I think I know what to do.

• ebo moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jul 24 2023, 2:12 PM