Fine-grained --fast-list-mode
Closed, ResolvedPublic

guilhem added a subscriber: guilhem.Sep 8 2014, 1:07 AM

With slightly over 1000 keys in my keyring, it is surprisingly slow to list all
865 sigs on my key:

    $ time gpg --list-sigs --with-colon $keyID >/dev/null
    real    0m22.061s

At first I naively thought the major bottleneck was caused by the trust
calculation, but changing the trust model doesn't seem to help:

    $ time gpg --trust-model=always --list-sigs --with-colon $keyID >/dev/null
    real    0m22.157s

While --fast-list-mode downs the execution time by a factor of 100 (0m0.220s),
the key UIDS are not displayed (which makes it impossible to know on which of
them the signature was added). I didn't benchmark the difference myself but I
don't expect it to be significant, as if I got RFC 4880 right, the UID packets
are being looped over when gpg inspects the signature packets. (OTOH the
primary UID of the signing keys are not printed either when --fast-list-mode is
set, which I can understand as doing so would require costly lookups through
the keyring.)

I wish the user had more fine-grain control on what to skip with
--fast-list-mode.

Thanks!

Guilhem.

guilhem set Version to 1.4.18 / 2.0.26.Sep 8 2014, 1:12 AM
guilhem set External Link to http://lists.gnupg.org/pipermail/gnupg-devel/2014-September/028739.html.Sep 10 2014, 9:17 AM
guilhem added a project: patch.
dkg added a subscriber: dkg.Apr 1 2015, 12:42 AM

I'm also seeing this extreme delay from gpg --list-sigs 2.1.2 on a large
keyring, particularly when using kbx. It seems likely that there is a bug here.

I created (1938) a new issue for the extreme slowness of --list-sigs on a
keybox. 1938 is most likely a bug, while 1710 is merely a quickfix for an
algorithmic issue in --list-sigs. However if with keybox “random access to the
keys is now really fast”, maybe it a proper fix could easily be implemented
instead. See also

http://lists.gnupg.org/pipermail/gnupg-devel/2015-February/029541.html
guilhem closed this task as Resolved.Apr 8 2015, 10:29 PM
guilhem claimed this task.