7 ms·
I'm surprised the faster decompression speed of zstd wasn't mentioned. Feels like a big win for cache (assuming decompress on read). A shame browsers don't sup
by andersmurphy 13d ago
I'm surprised the faster decompression speed of zstd wasn't mentioned. Feels like a big win for cache (assuming decompress on read).
A shame browsers don't support concatenating zstd frames (which zstd does support). Then you wouldn't need to decompress, just serve zstd straight to the browsers after concatenating the frames you care about.
- wood_spirit 13d agoWait, what? Don’t browsers support concatenated zstd streams? My reading - and I care because I’ve been using concatenation tricks in parquet - is that this is required by the standard. In the distant past I made a jinja2-like template system for server side rendering that precompressed the static bits and injected the short dynamic bits into the output stream as literals with some basic lz match rewriting in the following chunks etc. This kind of trick ought be better with zstd frames.
- andersmurphy 13d agoSadly they do not. They stop after the first frame (at least last time I tested it). They also don't always support window sizes above 8MB which means levels above 19 can fail to decompress (if they use the more than 8MB of window).