gh-91349: Adjust default compression level to 6 (down from 9) in gzip and tarfile #131470
Conversation
e2d0562 to
a2d0966
Compare
…n gzip and tarfile It is the default level used by most compression tools and a better tradeoff between speed and performance.
a2d0966 to
b17e21d
Compare
|
@merwok I added the versionchanged notes. and found another comment in tarfile.rst to adjust. You can review again. |
|
@gpshead you've replied multiple times to my questions on improving compression code with "PR welcome". maybe you would be interested in reviewing this PR? |
|
can anybody review the PR please? |
|
are you two saying that this fix will not be able to ship with python 3.14? |
set versionchanged to next Co-authored-by: Pieter Eendebak <pieter.eendebak@gmail.com>
set versionchanged to next
set versionchanged to next
|
done, adjusted all the |
|
wow, checking the source history it looks like "9" was used when the gzip module was added circa 1997. ironic, i'd have never expected that as a default. "6" being the bare "gzip" default value is just a well known thing. |
Misc/NEWS.d/next/Library/2025-03-19-12-41-42.gh-issue-91349.8eTOCP.rst
Outdated
Show resolved
Hide resolved
Misc/NEWS.d/next/Library/2025-03-19-12-41-42.gh-issue-91349.8eTOCP.rst
Outdated
Show resolved
Hide resolved
…TOCP.rst highlight function in rst file
|
@ethanfurman the PR says it's "pending review" from you, can you approve? @gpshead I adjusted the rst to highlight the function, as per the code suggestion. Indeed, the very first commit from April 1997 set the compression level to 9. It's been wrong for 28 years. :D I first came across this bug about 9 years ago, when using tornado (web framework). It took whole seconds to compress HTTP responses with the gzip=9 default and slow down every request (whole seconds of delay to compress a couple MB). Tornado was patched to set compresslevel=6 but I never came around to fix the interpreter until now. This PR is the fix of a lifetime :D |
|
It seems that I misinterpreted the status of 3.14: rc phase started today, we were in beta before. Would this change (accepted 2 days ago) have been ok for 3.14 @hugovk ? |
|
Entirely up to Hugo. I personally wouldn't bother trying to put this in 3.14 in the rc phase. The perhaps unusual default has been that way for decades now so there is no urgency in changing it. People who want speed are already passing their own compresslevel, or when possible, using a far more modern algorithm than venerable zlib based gzip. |
It is the default level used by most compression tools and a better tradeoff between speed and performance.
see discussion in #91349 (comment)
📚 Documentation preview 📚: https://cpython-previews--131470.org.readthedocs.build/