Chrome feature: Compression dictionary transport with Shared Brotli
1–10 of 40 posts
Re: Chrome feature: Compression dictionary transport with Shared Brotli
#2I never really understood with Google keeps pushing Brotli. LZ4 and ZStd both predate it by a couple of years, and seem to offer superior performance overall. Is it a Google-NIH thing?
Re: Chrome feature: Compression dictionary transport with Shared Brotli
#3Makes me wonder if rsync-style differential download would be more generally useful than "shared dictionary for shared brotli". The implementation is letting you reference a previously downloaded artifact using a hash value, which is the same starting point.
Re: Chrome feature: Compression dictionary transport with Shared Brotli
#4I never really understood with Google keeps pushing Brotli. LZ4 and ZStd both predate it by a couple of years, and seem to offer superior performance overall. Is it a Google-NIH thing?
Patents, maybe?
Re: Chrome feature: Compression dictionary transport with Shared Brotli
#5I never really understood with Google keeps pushing Brotli. LZ4 and ZStd both predate it by a couple of years, and seem to offer superior performance overall. Is it a Google-NIH thing?
Brotli usually compresses plain text better than ZSTD.
Re: Chrome feature: Compression dictionary transport with Shared Brotli
#6I never really understood with Google keeps pushing Brotli. LZ4 and ZStd both predate it by a couple of years, and seem to offer superior performance overall. Is it a Google-NIH thing?
Zstd no longer comes with a patent grant which I guess makes it kind of hard to actually use for some people.
Re: Chrome feature: Compression dictionary transport with Shared Brotli
#7Interesting two comment snippet from HN in 2018 about this: https://news.ycombinator.com/item?id=18720554
Re: Chrome feature: Compression dictionary transport with Shared Brotli
#8I never really understood with Google keeps pushing Brotli. LZ4 and ZStd both predate it by a couple of years, and seem to offer superior performance overall. Is it a Google-NIH thing?
Brotli usually compresses plain text better than ZSTD.
Both with dictionaries? Both without? Any links to benchmarks?
Re: Chrome feature: Compression dictionary transport with Shared Brotli
#9I never really understood with Google keeps pushing Brotli. LZ4 and ZStd both predate it by a couple of years, and seem to offer superior performance overall. Is it a Google-NIH thing?
They were designed more or less independently from each other, and your statement that Zstandard predates Brotli is also wrong (both around 2015). They are both designed to be much more efficient than DEFLATE in both time and size axes, but otherwise have little similarities. Zstandard is notable in its use of ANS, while Brotli is probably the first mainstream format that prominently uses a 2nd-order context model which was previously thought to be too slow. And Brotli is designed for web contents in mind, which made it excellent for small inputs with no prior. Zstandard has no such treatments but have a better performance when I/O can handle it, which makes it excellent for server jobs.
Re: Chrome feature: Compression dictionary transport with Shared Brotli
#10I never really understood with Google keeps pushing Brotli. LZ4 and ZStd both predate it by a couple of years, and seem to offer superior performance overall. Is it a Google-NIH thing?
Zstd no longer comes with a patent grant which I guess makes it kind of hard to actually use for some people.
Zstd is already used in the Linux kernel, and I would assume that any patents covering Lempel-Ziv and Huffman coding would have expired long ago. The situation around ANS also seems to have been resolved, see https://en.wikipedia.org/wiki/Asymmetric_numeral_systems#Tab... .