Release GIL during cipher update

[kcking]

Related to discussion in #11585.

[alex]

Can you share anything about the performance impact of this?

I'm modestly nervous about performance overhead for very small chunks, but what can you do 🙃

[kcking]

modestly nervous about performance overhead

Releasing the GIL should be order of microseconds. I could put together a benchmark for small blocks to see if the overhead is meaningful

[alex]

If you can share some performance numbers, we can get this merged. Thanks!

[alex]

Ooops, crossed streams :-)

Do you have any numbers for the impact of this on your application?

[kcking]

I can get some for you hopefully tonight, thanks for the quick review!

[alex]

Sounds great, thanks for the contribution

[reaperhulk]

Just a quick ping re: perf numbers 😄

[reaperhulk]

I ran some tests on an M1 Max (10 cores, 10 threads) and it appears GIL release is slower than single threading up to ~23kB update calls. I'd be curious if the same is true on other CPUs.

Some numbers:

Payload Size	Main	PR
64 bytes (100MB per thread)	16.6s	91s
23 kB (1024MB per thread)	4.7s	4.5s
1 MB (1024MB per thread)	4.3s	0.55s

These were derived using the following script and varying the size of DATA and TOTAL (100 for the first test, 1024 for the remaining).

import time
import concurrent.futures
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms

TOTAL = 1024 * 1024 * 100
DATA = bytes(64)
ITERATIONS = TOTAL // len(DATA)
KEY = bytes(32)

start = time.time()

def encrypt(num):
    buf = bytearray(len(DATA))
    c = Cipher(algorithms.ChaCha20(KEY, b"0" * 16), None)
    encryptor = c.encryptor()
    for _ in range(ITERATIONS):
        encryptor.update_into(DATA, buf)
    print(f"{num} thread complete. {ITERATIONS * len(DATA) / 1024 / 1024} MiB encrypted")


with concurrent.futures.ThreadPoolExecutor() as executor:
    executor.map(encrypt, range(0, 10))

print(time.time() - start)