gh-95534: Improve gzip reading speed by 10%

[rhpvorderman]

For motivation check the github issue. #95534
Performance figures before (the used gzip file is the tar source distribution from github):

./python -m pyperf timeit -s "import gzip; g=gzip.open('cpython-3.10.7.tar.gz', 'rb'); it=iter(lambda:g.read(128*1024), b'');" "for _ in it: pass"
.....................
Mean +- std dev: 301 ms +- 2 ms

after:

./python -m pyperf timeit -s "import gzip; g=gzip.open('cpython-3.10.7.tar.gz', 'rb'); it=iter(lambda:g.read(128*1024), b'');" "for _ in it: pass"
.....................
Mean +- std dev: 270 ms +- 1 ms

Performance tests where run with all optimizations enabled. I found that --enable-optimizations did not influence the result. So it can be verified without all the PGO stuff.

Change summary:

• There is now a gzip.READ_BUFFER_SIZE constant that is 128KB. Other programs that read in 128KB chunks: pigz and cat. So this seems best practice among good programs. Also it is faster than 8 kb chunks.
• a zlib._ZlibDecompressor was added. This is the _bz2.BZ2Decompressor ported to zlib. Since the zlib.Decompress object is better for in-memory decompression, the _ZlibDecompressor is hidden. It only makes sense in file decompression, and that is already implemented now in the gzip library. No need to bother the users with this.
• The ZlibDecompressor uses the older Cpython arrange_output_buffer functions, as those are faster and more appropriate for the use case.
• GzipFile.read has been optimized. There is no longer a unconsumed_tail member to write back to padded file. This is instead handled by the ZlibDecompressor itself, which has an internal buffer. _add_read_data has been inlined, as it was just two calls.

EDIT: While I am adding improvements anyway, I figured I could add another one-liner optimization now to the python -m gzip application. That read chunks in io.DEFAULT_BUFFER_SIZE previously, but has been updated now to use READ_BUFFER_SIZE chunks.
Results:
before:

Benchmark 1: cat cpython-3.10.7.tar.gz | ./python -m gzip -d > /dev/null
  Time (mean ± σ):     389.1 ms ±  12.0 ms    [User: 372.7 ms, System: 19.9 ms]
  Range (min … max):   370.9 ms … 410.2 ms    20 runs

After:

Benchmark 1: cat cpython-3.10.7.tar.gz | ./python -m gzip -d > /dev/null
  Time (mean ± σ):     320.5 ms ±  12.1 ms    [User: 306.4 ms, System: 17.6 ms]
  Range (min … max):   300.0 ms … 339.1 ms    20 runs

For comparison: pigz, the fastest zlib utilizing gzip decompressor, on a single thread. (igzip is faster, but utilizes ISA-L).

Benchmark 1: cat cpython-3.10.7.tar.gz | pigz -p 1 -d > /dev/null
  Time (mean ± σ):     293.8 ms ±   8.4 ms    [User: 288.5 ms, System: 17.0 ms]
  Range (min … max):   277.5 ms … 302.7 ms    20 runs

If we take the pure C pigz program as baseline, the amount of python overhead is reduced drastically from 30% to 10%.

• Issue: Faster decompression of gzip files #95534

[rhpvorderman]

Once all the reviewing is done, I will squash the commits.

[Fidget-Spinner]

Sorry I'm not a gzip expert so I can't review this. However I'd just like to say that you don't need to squash the commits, the core dev will squash them for you when merging!

Thanks for the thorough research and a solution to speeding up gzip!

[rhpvorderman]

However I'd just like to say that you don't need to squash the commits, the core dev will squash them for you when merging!

Thank you. It is good to know that "fix lock stuff" and "reorder code" will not get added to the list of commit messages.

Sorry I'm not a gzip expert so I can't review this.

Can you help me with the adress sanitizer? It is not happy about the way I added a new heap type, even though I seem to have done exactly the same thing as for the other heap types in the module. I am at a loss here. It seems to crash in state->ZlibDecompressorType = (PyTypeObject *)PyType_FromModuleAndSpec( . In python-isal I simply use static types as it is much easier, but since both the zlib and bz2 module are all heap types now I figure there must be some important advantage.

[gpshead]

most of my comments are fairly minor, overall I think this code is well written.

[gpshead]

Describe what type this must be (usually bytes?) so that nobody is confused thinking it is a Python dict.

Consider using O! in your format below to have the API do a type check for you rather than failing later on when its use is attempted via the buffer API.

[rhpvorderman]

The problem with O! is that it cannot correctly accept bytes and bytearray simultaneously. Or is there a better solution for this?

[bedevere-bot]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[rhpvorderman]

most of my comments are fairly minor, overall I think this code is well written.

As stated, most of the code is copied from the Cpython codebase is elsewhere, so I do not want to take credits for it. Thank you for the review. I have updated the code according to your comments.

EDIT: I did notice a significant oversight when revisiting: I have not added any testing code for _ZlibDecompressor. This can be very easily be arranged (Python-isal already has a full test suite). On the other hand _ZlibDecompressor's only use case is usage in the gzip module. So it can also be considered sufficiently tested using the current test suite.

EDIT: Added the test suite (adapted from test_bz2.py).

[rhpvorderman]

As a heads up, I see this has the "awaiting changes" label. The changes have already been made 12 days ago.

[Fidget-Spinner]

@rhpvorderman you can re-trigger the bot. See the comment here #97664 (comment).

[rhpvorderman]

Whoop sorry, 🤦‍♂️ . Should have read that better. Usually I contribute to much smaller projects where such things are commonly not used.

I have made the requested changes; please review again

[bedevere-bot]

Thanks for making the requested changes!

@gpshead: please review the changes made to this pull request.