4 ms·
The best thing about zstd is its zlibWrapper, which lets you write code as if you’re consuming zlib-compressed files while transparently working with zlib-, zst
by stochastic_monk 8y ago
The best thing about zstd is its zlibWrapper, which lets you write code as if you’re consuming zlib-compressed files while transparently working with zlib-, zstd-, or uncompressed files. I build several of my tools with zstd for this reason.
- loeg 8y agozlibWrapper seems useful if you're specifically using the low level zlib APIs already and don't want to change your code very much. But if you just use zopen() or similar, or are willing to make minor changes, I don't see much benefit. (Especially given the performance gap vs native zstd APIs). I have seen some fopencookie(3)-based zstd/zlib/xz/etc FILE-object wrappers floating around that make it pretty easy to work with any compression library's streaming APIs.
- stochastic_monk 8y agozlib is standard in my field, so being compatible is a big plus. I should do some testing with the zstd API, though. Thanks for the performance discrepancy heads-up!
- hyc_symas 8y agoDid someone say compression wrapper? https://github.com/hyc/polyZ https://github.com/hyc/polyZ Did that 4 years ago. > The snappy wrapper can serve as a frontend for bzip2, lz4, lz4hc, lzma, lzo, and zlib. > The zlib wrapper can serve as a frontend for bzip2, lz4, lz4hc, lzma, lzo, and snappy. Very handy for quickly benchmarking multiple compressors without having to write multiple implementations of the same test code. As illustrated here http://www.lmdb.tech/bench/inmem/compress/ http://www.lmdb.tech/bench/inmem/compress/ Feel free to PR support for brotli or zstd or anything else that comes along.