It seemed I was wrong that it is due to buffering.
In the use case of --sign and --encrypt, hashing is done with IOBUF's 64KiB buffer (already).

I'm trying to use a thread for computation of hashing. It works, but no performance gain, due to nPth.
I do:

npth_unprotect ();
gcry_md_write (mfx->md, mfx->buf, mfx->written);
npth_protect ();

to expect hashing is done in parallel.

So far, it doesn't go well. Another thread is waiting the lock when it computes the hash. I need to introduce more controlled threads.

This is a patch for master (which uses nPth for gpg):

With this patch --sign + --encrypt can be as fast as --sign.

Updated the patch:

It uses double-buffer.

I can observe it's a bit faster (lower latency), due to hiding input+memcpy things while it computes the hash.

Am I correct that the reason for the speed up is that it can use a second CPU's engine. If there is a real performance improvement here, we should add this for example using a --compatibility-flag. This way we can gather experience and eventually make it the default. The compatibility flags won't introduce an API incompatibility.

So some more data from 2.4.3. Once unpatched and once with your patch.

The problem is that heat seems to be an issue or at least some boosting of some cores or so. While continuning the tests the results were slower and slower. So after testing with your patched version I reinstalled 2.4.3 unpatched to repeat the tests twice again with that and got different, even slower results.

Still there is clearly a measurable improvement here.

But even with your patch with signing my disk io never went above 350MB/s for sign & encrypt. Where libgcrypt itself munched through 2200MB/s SHA256 hashing on the same system in the bench slope test and the disk does sequential read writes at around 3000MB/s. (See F4883964 )

Measure-Command { gpg --yes -z0 -o 10gb-ocb.tar.gpg -er ldata-aead .\10gb.tar }
Unpatched: First test: 11.3s -> Last tests: 18.3s 21.8s
Patched: 18.5s 22.4s 18.3s

Measure-Command { gpg --yes -z0 -o 10gb-ocb-sig.tar.gpg -er ldata-aead -su ldata-aead .\10gb.tar }
Unpatched: First test: 49.2s -> Last tests: 65s, 62s
Patched: 35.1s 30.7s 39,3s

Update the patch to allow --compatibility-flags hashing-in-parallel.

My vote would be to invert the logic of the last patch and add "no-hashing-in-parallel" as a compatibility flag and make the other behavior default and then to push it at least to master or even to 2.4.