Page MenuHome GnuPG

Kleopatra: Performance problems when encrypting large files
Testing, NormalPublic

Description

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.

Edit 2024-01-11 (ikloecker): The problem exists for all crypto operations (sign, encrypt, decrypt, verify). For OpenPGP the problem is tracked by this task. For S/MIME it's tracked by T6928: Kleopatra: Speed up S/MIME crypto operations for large files (on Windows).

Event Timeline

cklassen created this object in space S1 Public.

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

cklassen renamed this task from Kleopatra: Performance problems when encrypting large files to Kleopatra: Performance problems when encrypting large files without compression.Jan 20 2023, 11:09 AM
cklassen updated the task description. (Show Details)
werner triaged this task as Normal priority.Jan 20 2023, 1:31 PM
werner added a subscriber: werner.

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

aheinecke renamed this task from Kleopatra: Performance problems when encrypting large files without compression to Kleopatra: Performance problems when encrypting large files.Jan 23 2023, 10:56 AM
aheinecke added projects: Restricted Project, gpgme.

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.

ikloecker moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.
ikloecker changed the task status from Open to Testing.Jan 11 2024, 9:34 AM
ikloecker updated the task description. (Show Details)

The problem has been addressed for all OpenPGP crypto operations on files.