I edited this task a bit: For compression we have T6332
For Archives passed to Gpgtar we have: T6342

Some technical points:

There are two issues here:

1. The overhead due to QT based processing.
2. The compression takes long and gpg used to had no way to detected already cmpressed data when the data was piped to gpg (as Kleopatra) does. See T6332.

The introduction of --override-compliance-check actually hid the real
cause for the signature verification problem in de-vs mode for the
Ed25519 key. The real fix is to handle the EdDSA algorithm in
gnupg_pk_is_allowed.

There is another issue about the performance of Kleopatra when encrypting large archive files

I see no reason to force a certain order of actions on the users, i.e. first they have to certify a certificate and only then they can give this certificate certification power.

On the mailing list I wrote down my test results for en- and decrypting files (1-10 GB) with GnuPG and Gpg4win/Kleopatra. The encryption always ran with compression. Kleopatra needed more than 11 minutes to encrypt a file that is 10 GB big. Today I tested the encryption again but this time I added

compress-level 0

to gpg.conf (I also tried to add bzip2-compress-level 0 and then only compress-algo uncompressed because Bernhard was suggesting that in the mailing list but it made no difference).