Control: forwarded 775933 https://sourceforge.net/p/enigmail/bugs/389/
Hi Andrew-- On Wed 2015-01-21 12:25:13 -0500, Andrew Gallagher wrote: > Enigmail appears to call 'gpg --list-keys' when trying to work out if it > should encrypt an email, even if that mail has only one recipient. This means > slurping up every single key ID into memory, required or not. It also causes > gpg to walk its entire database, which is ridiculously inefficient - with a > large keyring and gpg2 this can take several minutes, during which time gpg > hogs 99% of CPU. (gpg1 is faster, but there is still a noticeable delay) Yep, i've seen this problem myself, and have initially tried to get it fixed upstream in gpg by getting gpg to speed up the --list-keys output. We've had some reasonable speedup already there. But i agree with you that enigmail should also avoid doing this operation where possible. I've just forwarded the bug upstream to https://sourceforge.net/p/enigmail/bugs/389/ > Is this all really necessary? It would be hundreds of times faster to call > 'gpg --list-keys $email' for each recipient in turn. This is likely true if you have a large keyring and a few recipients, but might not be the case if you have a small keyring and many recipients :/ However, this is something amenable to profiling, and the speedup in the large-keyring case is substantial (i've measured it locally and reported those measurements at the upstream bug). BTW, which version of gpg2 are you using? I found that gpg2 2.1.2 (from debian experimental) is actually significantly faster than gpg 1.4.18. --dkg
signature.asc
Description: PGP signature
