diff options
author | Daniel Edgecumbe <git@esotericnonsense.com> | 2019-09-02 22:09:15 +0100 |
---|---|---|
committer | Denys Vlasenko <vda.linux@googlemail.com> | 2019-09-05 13:26:58 +0200 |
commit | c660cc1b7714fffbac95c9378ff4b73de650a6de (patch) | |
tree | e05f4421fc7f0e5c6b9bf39e1e45fbdaedc80769 /shell/hush_test/hush-parsing/bkslash_eof1.right | |
parent | ca5d86d52c979cef05a614fb725870c10be9b265 (diff) | |
download | 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 'shell/hush_test/hush-parsing/bkslash_eof1.right')
0 files changed, 0 insertions, 0 deletions