When encrypting large files (without compression) the difference between GnuPG and Kleopatra becomes significant because Kleopatra needs around 5-6x more time than GnuPG. That's why it would be great to increase the performance of Kleopatra.
Description
Status | Assigned | Task | ||
---|---|---|---|---|
Open | None | T6351 Kleopatra: Performance problems when encrypting large files | ||
Resolved | aheinecke | T6332 GPG: Extend / rework "is_file_compressed" | ||
Resolved | ikloecker | T6530 GPGME / QGpgME Extend Archivejobs to accept input / output from a filename | ||
Open | None | T6550 GpgME / QGpgME Extend non-archive jobs to accept input / output from a filename |
Event Timeline
There is another issue about the performance of Kleopatra when encrypting large archive files
There are two issues here:
- The overhead due to QT based processing.
- 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 second issue has been fixed for the majority of compressed documents and some image formats. This will be released with gnupg 2.4.1 and 2.2.43.
I edited this task a bit: For compression we have T6332
For Archives passed to Gpgtar we have: T6342
I would like this issue to be for the case https://lists.gnupg.org/pipermail/gnupg-users/2023-January/066397.html that:
Encryption:
Size | GnuPG | Gpg4win
1GB | 38 sec. | 1 min. 8 sec.
1GB | 37 sec. | 1 min. 7 sec.
2GB | 1 min. 14 sec. | 2 min. 15 sec.
2GB | 1 min. 14 sec. | 2 min. 14 sec.
5GB | 3 min. 10 sec. | 6 min. 10 sec.
5GB | 3 min. 6 sec. | 5 min. 34 sec.
10GB | 6 min. 28 sec. | 11 min. 21 sec.
10GB | 6 min. 21 sec. | 11 min. 6 sec.
Results of decryption:
Size | GnuPG | Gpg4win
1GB | 3 sec. | 36 sec.
1GB | 3 sec. | 34 sec.
2GB | 10 sec. | 1 min. 13 sec.
2GB | 7 sec. | 1 min. 12 sec.
5GB | 22 sec. | 3 min. 1 sec.
5GB | 19 sec. | 3 min. 2 sec.
10GB | 1 min. 3 sec. | 5 min. 52 sec.
10GB | 1 min. 7 sec. | 6 min. 5 sec.
Which would be solved in my opinion if we would have the filenames for encryption and decryption passed directly to GnuPG and not go through the GPGME callback layers. This is very similar to what T6342 is about. But different enough that it warrants its own issue.