summaryrefslogtreecommitdiff
path: root/testsuite/bunzip2
diff options
context:
space:
mode:
authorDaniel Edgecumbe2019-09-02 22:09:15 +0100
committerDenys Vlasenko2019-09-05 13:26:58 +0200
commitc660cc1b7714fffbac95c9378ff4b73de650a6de (patch)
treee05f4421fc7f0e5c6b9bf39e1e45fbdaedc80769 /testsuite/bunzip2
parentca5d86d52c979cef05a614fb725870c10be9b265 (diff)
downloadbusybox-c660cc1b7714fffbac95c9378ff4b73de650a6de.zip
busybox-c660cc1b7714fffbac95c9378ff4b73de650a6de.tar.gz
gzip: set default compression level to 6 when CONFIG_FEATURE_GZIP_LEVELS=n
With this change, GNU gzip -n and BusyBox gzip now produce identical output assuming that CONFIG_GZIP_FAST=2. >> Excuse me, but I wonder one thing: Why should we follow >> strictly with gzip on the no-options default behavior? > First, the default 6 compression level is a de-facto standard. BSD gzip > and Apple gzip (on macOS) use this default as well. So there is a > reasonable expectation that different gzip implementations act the same. > For instance, if the default for busybox gzip becomes 9, then someone > writing a script using busybox gzip could reasonably expect that the > compression level will still be 9 when the same script is run on another > system. That would be wrong. Implementations should not deviate from > de-facto standards without a strong reason. > > Second, the inherent reason for this default has not gone away. While > processor speeds have exploded since the default was set, so has the > typical size of compressed files. Multiple gigabytes are nothing unusual > these days. And gzip is often used for compression on the fly, precisely > because it offers a good compromise between speed and compression ratio. > So I believe 6 continues to be a reasonable default. function old new delta deflate 939 927 -12 Signed-off-by: Daniel Edgecumbe <git@esotericnonsense.com> Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Diffstat (limited to 'testsuite/bunzip2')
0 files changed, 0 insertions, 0 deletions