2 ms·

Let's look at the most interesting there: fastest encoding: 210,194,996 bytes, 0.333 sec., 0.371 sec., lz4 -1 fastest decoding: 169,476,113 bytes, 2.072 sec

by eln1 11y ago

Let's look at the most interesting there: fastest encoding: 210,194,996 bytes, 0.333 sec., 0.371 sec., lz4 -1 fastest decoding: 169,476,113 bytes, 2.072 sec., 0.352 sec., lz4 -9 149,642,742 bytes, 2.069 sec., 0.646 sec., zhuff_beta -c0 -t1 gzip-alternative: 135,723,691 bytes, 8.318 sec., 1.677 sec., bro -q 3 114,602,026 bytes, 8.403 sec., 1.218 sec., lzturbo -32 -p1 -b800 prepacked: 104,094,380 bytes, 2313.780 sec., 1.693 sec., bro -q 10 90,239,627 bytes, 680.976 sec., 1.170 sec., lzturbo -39 -p1 -b800 best compression: 82,891,405 bytes, 882.513 sec., 4.597 sec., lzturbo -49 -p1 -b800 77,286,010 bytes, 6497.059 sec., 7.715 sec., glza there are missing e.g. density, zpaq, and comments there suggest that brotli doesn't look that good for other than text data ...

Sanmayce_Kaze 11y ago
You miss the point, your list is meaningful only in general compression cases, the Brotli thread (where we are) is all about boosting textual decompression while having/exploiting little resources (RAM mostly) as in the cases of Web Browsers. As one (Jyrki) of co-authors commented: ``` For more clarity on the situation, you could compare LZMA, LZHAM and brotli at the same decoding memory use. Possibly values between 1-4 MB (window size 20-22) are the most relevant for the HTTP content encoding. Unlike in a compression benchmark, there are a lot of other things going on in a browser, and the allocated memory at decoding time is a critically scarce resource. ``` Source: http://google-opensource.blogspot.bg/2015/09/introducing-brotli-new-compression.html http://google-opensource.blogspot.bg/2015/09/introducing-bro...
Sanmayce_Kaze 11y ago
Let's dramatize the next 2 scenarios: - 10Mbps or 1MB/s connection; - 100Mbps or 10MB/s connection. The goal is to receive in our browser those 812,392,384 bytes as quickly as possible, in first case the winner is 77,286,010 bytes compressor, in second the winner is 90,239,627 bytes compressor, yes? In first case transfer_time + decompression_time = 77s + 7s = 84s In second case transfer_time + decompression_time = 9s + 1s = 10s Now, you see that even in Web Browsing scenario the best performer is not established, right?

by eln1 11y ago

Sanmayce_Kaze 11y ago

You miss the point, your list is meaningful only in general compression cases, the Brotli thread (where we are) is all about boosting textual decompression while having/exploiting little resources (RAM mostly) as in the cases of Web Browsers. As one (Jyrki) of co-authors commented: ``` For more clarity on the situation, you could compare LZMA, LZHAM and brotli at the same decoding memory use. Possibly values between 1-4 MB (window size 20-22) are the most relevant for the HTTP content encoding. Unlike in a compression benchmark, there are a lot of other things going on in a browser, and the allocated memory at decoding time is a critically scarce resource. ``` Source: http://google-opensource.blogspot.bg/2015/09/introducing-brotli-new-compression.html http://google-opensource.blogspot.bg/2015/09/introducing-bro...

Sanmayce_Kaze 11y ago

Let's dramatize the next 2 scenarios: - 10Mbps or 1MB/s connection; - 100Mbps or 10MB/s connection. The goal is to receive in our browser those 812,392,384 bytes as quickly as possible, in first case the winner is 77,286,010 bytes compressor, in second the winner is 90,239,627 bytes compressor, yes? In first case transfer_time + decompression_time = 77s + 7s = 84s In second case transfer_time + decompression_time = 9s + 1s = 10s Now, you see that even in Web Browsing scenario the best performer is not established, right?