DB signature verification is slow #26
Comments
|
edit: I've proposed a new API upstream: https://dev.gnupg.org/T6369 |
|
Since there was no upstream activity on this (code wise) I proposed another patch: https://dev.gnupg.org/T6369#186304 |
lazka
added a commit
to lazka/MSYS2-packages
that referenced
this issue
May 20, 2024
See msys2/msys2-pacman#26 See https://dev.gnupg.org/T6369 This saves a gpg spawn for every gpgme_get_key() call, for example around 100ms when starting pacman.
lazka
added a commit
to lazka/MSYS2-packages
that referenced
this issue
May 21, 2024
See msys2/msys2-pacman#26 See https://dev.gnupg.org/T6369 This saves a gpg spawn for every gpgme_get_key() call, for example around 100ms when starting pacman.
|
Since the patch we are down to 0.450s Needs a new evaluation re what is the slowest part now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
example:
time pacman-0.598s- this will load all databases and verify their signatures using gpgme.Most of the time is spend in
_alpm_gpgme_checksig, skipping it brings us down to0.036s.Things I've tried:
Build libgcrypt with asm support (needs some hackery to detect cygwin in some places and enable USE_MS_ABI). This didn't change much performance wise, and I don't feel comfortable patching this downstream. Upstreaming would be a possibility.
Bump the IO buffer size for gpgme in pacman ->only saves 10ms https://gist.github.com/lazka/542641bc69b36630dc6d652699c8773a
Try to re-use the gpgme context in _alpm_gpgme_checksig.
This saves 100ms, but requires some logic from gpgme being pulled into libalpm, which is not very nice. We could ask gpgme for a gpgme_get_key() that doesn't create a new context.
https://gist.github.com/lazka/f8076fbd3beec6b4eff2a7e34b3ae70e
With that we are down to
0.474s, but this doesn't feel upstreamable.. likely the difference is less on Linux.I'm gonna leave that as is for now.
The text was updated successfully, but these errors were encountered: