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.
Wait, 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.
Comments
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.
Wait, 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.
Sadly 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).