zstd VS compress

This VFS will read a sqlite file after it has been compressed using [zstd seekable format](https://github.com/facebook/zstd/blob/dev/contrib/seekable_f...). Built to support read-only databases for full-text search. Benchmarks are provided in README.

Of course, you may get different results with another dataset.

gzip (zlib -6) [ratio=32%] [compr=35Mo/s] [dec=407Mo/s]

zstd (zstd -2) [ratio=32%] [compr=356Mo/s] [dec=1067Mo/s]

NB1: The default for zstd is -3, but the table only had -2. The difference is probably small. The range is 1-22 for zstd and 1-9 for gzip.

NB2: The default program for gzip (at least with Debian) is the executable from zlib. With my workflows, libdeflate-gzip iscompatible and noticably faster.

NB3: This benchmark is 2 years old. The latest releases of zstd are much better, see https://github.com/facebook/zstd/releases

For a high compression, according to this benchmark xz can do slightly better, if you're willing to pay a 10× penalty on decompression.

xz -9 [ratio=23%] [compr=2.6Mo/s] [dec=88Mo/s]

zstd -9 [ratio=23%] [compr=2.6Mo/s] [dec=88Mo/s]

Compression, synchronization and backup systems often use rolling hash to implement "content-defined chunking", an effective form of deduplication.

In optimized implementations, Rabin-Karp is likely to be the bottleneck. See for instance https://github.com/facebook/zstd/pull/2483 which replaces a Rabin-Karp variant by a >2x faster Gear-Hashing.

Get the data https://publicdistst.blob.core.windows.net/data/root.tar.zst magnet:?xt=urn:btih:84931cd80409ba6331f2fcfbe64ba64d4381aec5&dn=root.tar.zst How to extract https://github.com/facebook/zstd Linux (debian): `sudo apt install zstd` ``` tar -I 'zstd -d -T0' -xvf root.tar.zst ```

I've done that experiment with zstd before.

https://github.com/facebook/zstd/blob/dev/programs/zstd.1.md...

Not sure about brotli though.

If you want this functionality in zstd itself, check this out: https://github.com/facebook/zstd/pull/2349

There's a pure-go zstd at https://github.com/klauspost/compress - it's likely faster than running the upstream zstd under Wazero.

It's no surprise that "fast" Go libraries are actually just assembly: https://github.com/klauspost/compress/blob/master/zstd/seqdec_amd64.s (just one file out of several, for just one architecture, for just one compression algorithm!)

There is a reasonably feature complete implementation of Zstd for Go: https://github.com/klauspost/compress/tree/master/zstd

It may not offer the same API 1:1, but it has no interoperability issues that I've encountered. So, I just think no one has bothered to implement it in Rust because most use cases don't mind the added bloat you're talking about. Plus, other comments I've seen suggest that you can actually tune the size of the zstd library, although I'm not sure if the Rust bindings expose that.

Thanks again for your review/comment!!! Btw, are you the author of this repo https://github.com/klauspost/compress because I love it!!!

I noticed Github returns "This page is taking too long to load" with status code 502 for https://github.com/klauspost/compress but rest of their urls works fine. Anyone know why would that be the case ?

Cloning the repo works perfectly well.

git clone https://github.com/klauspost/compress

Recent versions of zstd definitely don't obsolete LZ4, or else I don't think the author would still be contributing to both...

And if you're going to play with Snappy, you might find S2, which was linked on HN relatively recently, interesting. [1]

[1] - https://github.com/klauspost/compress/tree/master/s2

Compression method appears to be zstandard and uses https://github.com/klauspost/compress, for those wondering like I was.

OMG u/klauspost is this you? https://github.com/klauspost/compress/tree/master/s2