<html xmlns="http://www.w3.org/1999/xhtml" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office"><head><!--[if gte mso 9]><xml><o:OfficeDocumentSettings><o:AllowPNG/><o:PixelsPerInch>96</o:PixelsPerInch></o:OfficeDocumentSettings></xml><![endif]--></head><body>
Can someone please remove my email address from this group! This has nothing to do with me!<div><br><br><a href="https://overview.mail.yahoo.com/?.src=iOS">Sent from Yahoo Mail for iPhone</a><br><br><p class="yahoo-quoted-begin" style="font-size: 15px; color: #715FFA; padding-top: 15px; margin-top: 0">On Tuesday, January 17, 2023, 5:10 AM, Andre Heinecke via Gnupg-users <gnupg-users@gnupg.org> wrote:</p><blockquote class="iosymail"><div dir="ltr">Hi,<br clear="none"><br clear="none">On Sunday 15 January 2023 10:52:23 CET Christoph Klassen wrote:<br clear="none">> When I was testing the decryption I also tried "gpg --decrypt <br clear="none">> test_file.gpg" (without output file) with the 10 GB file and it took 8 <br clear="none">> minutes and 47 seconds. I was wondering why it took longer when GnuPG <br clear="none">> didn't need to create an output file.<br clear="none"><br clear="none">Yes that is expected. Gpg encrypt and decrypt with AES should be mostly IO <br clear="none">Bound as with AES-NI instructions it is really fast in the CPU. So not writing <br clear="none">the output to disk will result in faster operations. And one of the biggest <br clear="none">differences you get is when you encrypt / decrypt on a faster disk.<br clear="none"><br clear="none"><br clear="none">Another big difference what you will see in the perfomance of GnuPG is if you <br clear="none">use -z 0 which disables compression. Currently GnuPG on the command line <br clear="none">disables compression when the input file name already looks compressed <br clear="none">depending on the file name. We want to improve that, especially since Kleopatra <br clear="none">hands the filename only in a way that is not used in that compression <br clear="none">calculation. E.g. Adding Media data formats there might already help in a lot <br clear="none">of use cases. For uncompressable output, like random data, this will make the <br clear="none">largest difference. You can put "compress-level 0" into your gpg.conf to cause <br clear="none">Kleopatra to also use that.<br clear="none"><br clear="none">That issue is: <a shape="rect" href="https://dev.gnupg.org/T6332 " target="_blank">https://dev.gnupg.org/T6332 </a> If you could do a run of your <br clear="none">tests and comment in that issue with the results that would be helpful.<br clear="none"><br clear="none"><br clear="none">It does not surprise me that Kleopatra is much slower. Due to our Architecture <br clear="none">Kleopatra passes Data, through GPGME directly to GnuPG. This results in <br clear="none">additional overhead but gives us more flexibility what kind of data we encrypt <br clear="none">/ decrypt. E.g. a mail or something that is not even written on the File <br clear="none">system.<br clear="none"><br clear="none">For some parts we want to change that. Most notably Ingo is currently working <br clear="none">on Gpgtar. Gpgtar can nowadays directly encrypt / decrypt so there is no need <br clear="none">to pipe the input / output of GnuPG to or from GpgTar. Using GpgTar directly <br clear="none">should help a lot when working with larger Archives. <a shape="rect" href="https://dev.gnupg.org/" target="_blank">https://dev.gnupg.org/</a><br clear="none">T5478<br clear="none"><br clear="none">We also already increased the buffer size in GPGME to reduce the number of <br clear="none">callbacks we do internally but there can be more optimization there. Currently <br clear="none">our recommendation for Large Data is to use the command line directly, which <br clear="none">will always be fastest as there is no overhead.<div class="yqt4007798639" id="yqtfd37128"><br clear="none"><br clear="none">> Did someone of you also try to en-/decrypt larger files? Maybe even <br clear="none">> files that are larger than 1 TB? It would be really nice to know how <br clear="none">> long GnuPG and Gpg4win are busy with such large files.</div><br clear="none"><br clear="none">I think my largest tests were around 40GB. But I don't have the numbers <br clear="none">anymore, the testing I did there was mostly because there were reports that <br clear="none">Kleopatra crashes on such large files.<br clear="none"><br clear="none"><br clear="none">Maybe you can open a ticket for this with a reference to https://<br clear="none">dev.gnupg.org/T5478 about performance problems when decrypting / encrypting <br clear="none">large files (In contrast to archives.)<br clear="none"><br clear="none"><br clear="none">Best Regards,<br clear="none">Andre<br clear="none"><br clear="none">P.S. we are currently also looking at the startup / initial keycache building <br clear="none">time of Kleopatra. This might also be intresting for those looking at Kleo <br clear="none">performance. <a shape="rect" href="https://dev.gnupg.org/T6259" target="_blank">https://dev.gnupg.org/T6259</a><br clear="none"><br clear="none">-- <br clear="none">GnuPG.com - a brand of g10 Code, the GnuPG experts.<br clear="none"><br clear="none">g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459<br clear="none">GF Werner Koch, USt-Id DE215605608, www.g10code.com.<br clear="none"><br clear="none">GnuPG e.V., Rochusstr. 44, D-40479 Düsseldorf. VR 11482 Düsseldorf<br clear="none">Vorstand: W.Koch, B.Reiter, A.Heinecke Mail: <a shape="rect" ymailto="mailto:board@gnupg.org" href="mailto:board@gnupg.org">board@gnupg.org</a><br clear="none">Finanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-211-28010702</div><div class="yqt4007798639" id="yqtfd36527">_______________________________________________<br clear="none">Gnupg-users mailing list<br clear="none"><a shape="rect" ymailto="mailto:Gnupg-users@gnupg.org" href="mailto:Gnupg-users@gnupg.org">Gnupg-users@gnupg.org</a><br clear="none"><a shape="rect" href="https://lists.gnupg.org/mailman/listinfo/gnupg-users" target="_blank">https://lists.gnupg.org/mailman/listinfo/gnupg-users</a><br clear="none"></div><blockquote></blockquote></blockquote></div>
</body></html>