Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DB signature verification is slow #26

Open
lazka opened this issue Feb 12, 2023 · 1 comment
Open

DB signature verification is slow #26

lazka opened this issue Feb 12, 2023 · 1 comment

Comments

@lazka
Copy link
Member

lazka commented Feb 12, 2023

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 to 0.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.

@lazka
Copy link
Member Author

lazka commented Feb 12, 2023

gpgme_get_key() really has a 40% overhead due to the extra context even on Linux. I'm going to ask upstream.

edit: I've proposed a new API upstream: https://dev.gnupg.org/T6369

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant