How does zstd compare with brotli? Would it be a better compression standard for http responses?
Unfortunately, we have a strict requirement that the decompression be done in pure Java (and ideally providing an InputStream interface). The official Brotli repo includes a pure Java decompression library that took about three lines of code to drop in next to our gzip support, while zstd had nothing suitable (a JNI wrapper is not an option, and the Java decompressor at [1] does not provide an streaming interface). Writing my own Java decompressor for zstd sounded like a fun project, but that would have been too much like yak shaving; brotli is good enough.
[1] https://github.com/airlift/aircompressor/tree/master/src/mai...
I never was able to locate a file that compresses better with zstd than with brotli, if you use the same window size in both.
The car analogy in using different window sizes is to drive on 1st gear with one car and drive on 5th gear with other, i.e., meaningless comparisons. One needs to use the same window size with both algos to be able to understand the performance potential in them. When one does that, brotli always wins in density and most of the time on compression speed to a given density. Zstd wins in decompression speed, but neither of them is slow (think 600 MB/s vs. 900 MB/s).
https://github.com/google/brotli/issues/642 is relatively well conducted, but covers the slow+dense and large window compression only.
I am working on that very question! Zstd's support for creating and using custom dictionaries opens the door to significant efficiencies. As described in the post though, dictionaries make compression a more complicated thing to use, and so there are lots of questions about how to apply that to the public internet in a way that's cross-compatible and secure. In short: it's something we're actively exploring.
[1] http://quixdb.github.io/squash-benchmark/unstable/?dataset=e...
The hard part is that compression is already an attack vector for the web (e.g., CRIME [2], BREACH [3], et al.). We want to make sure that we're not eroding or unduly complicating that situation [4].
[1] https://tools.ietf.org/html/draft-lee-sdch-spec-00 [2] https://en.wikipedia.org/wiki/CRIME [3] https://en.wikipedia.org/wiki/BREACH [4] https://tools.ietf.org/html/draft-kucherawy-httpbis-dict-sec...
Brotli is naturally limited to 16 MB of memory use whereas ZStd makes less attempts to reduce memory use. If you want to use more memory with Brotli, you need to use another flag '--large_window' instead of '--window', to indicate that you really want it, whereas zstd uses a lot of memory more silently.
When you compare compression levels, you should compare with same memory consumption -- and if you do that, brotli tends to win by 5 %.
When in doubt in benchmarking, run brotli with --large_window 30
https://encode.ru/threads/2947-large-window-brotli-results-a... is a summary of a recent large-scale experiment of a large variety of compressors, including brotli, zstd and LZMA.
Ever heard of flag `--ultra` ? Without it, zstd memory usage will be limited to 8 MB. It has been there since, forever.
would be wonderful to see benchmarking with real data and with realistic (and same from one algorithm to the next) window sizes
When you are comparing brotli and zstd, are you focusing on the highest quality/compression level, but varying the window size?
For us, lower compression levels (1-3) are our primary focus. We care about the highest levels for benchmarks, but it isn't our focus. When we are benchmarking zstd we focus on the lower levels, since they are the most important to us. When we think about a smaller window size, we generally think about faster compression.
When we comparing against brotli, the question we're asking is, how does brotli compare to level 3. When you're benchmarking zstd, I suspect you're asking the question, how does the highest zstd level compare to the highest brotli quality for the same window size, is that right?
For example, a mobile client might prefer to have no more than 512 kB sliding window due to design of its memory system or for multi-processing reasons. There, a static resource can still be encoded to the smallest size with extremely slow encoding (quality 9-11) -- but for one-use we'd still prefer a faster encoding (quality 6 or so).
Thank you for explaining your focus. Did you arrive to that by doing economic calculations or was it to have minimal changes to situation with no compression?
That said, we still see users of the stronger compression levels.
In my back-of-the-envelope financial analysis, the highest economic impact is when I can reduce people's need to wait for data to arrive. There we often use relatively slow compression even when it is for one use only. Computers are quite a lot (~1000x) cheaper than people's time.