zstd VS Bazel

> In such cases, the serialized binary are mostly in 200~1000 bytes. Not big enough for zstd to work

You're not referring to the same dictionary that I am. Look at --train in [1].

If you have a training corpus of representative data, you can generate a dictionary that you preshare on both sides which will perform much better for very small binaries (including 200-1k bytes).

If you want maximum flexibility (i.e. you don't know the universe of representative messages ahead of time or you want maximum compression performance), you can gather this corpus transparently as messages are generated & then generate a dictionary & attach it as sideband metadata to a message. You'll probably need to defer the decoding if it references a dictionary not yet received (i.e. send delivers messages out-of-order from generation). There are other techniques you can apply, but the general rule is that your custom encoding scheme is unlikely to outperform zstd + a representative training corpus. If it does, you'd need to actually show this rather than try to argue from first principles.

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

> Doesn't take large amount of GPU resources

This is an understatement, zstd dictionary compression and decompression are blazingly fast: https://github.com/facebook/zstd/blob/dev/README.md#the-case...

My real-world use case for this was JSON files in a particular schema, and the results were fantastic.

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

Wow, if you curl it, there's a lot of boilerplate code there.

Maybe built using Bazel?

https://bazel.build

Bazel by Google

Luckily a feature to limit the disk cache size is in development: https://github.com/bazelbuild/bazel/issues/5139

This is a problem that Bazel (https://bazel.build) solves in a very convenient way. You can just keep using the paths relative to the repository root, and as long as you properly declare your test needs that file it will access it without problems. Or you can use the runfile libraries to access them too.

When doing research for this lab exercise I looked at both vcpkg and conan. Both are package managers that would automate the installation and configuration of my program with its dependencies. However, when it came to releasing and sharing my program my options were limited. For example, the central public registry for conan packages is conan-center, but these packages are curated and the process is very involved. There was no way conan-center would accept a class project like mine. Alternatively, I could host a conan package on a public Artifactory repository, but accessing the package requires users to add the repository to their conan remote. This already sounded like too many steps to expect regular users to follow - I already haven't setup any conan remotes, there's no way I could expect regular users to know about conan remotes, let alone have conan installed on their system. After discussing with people online and consulting my instructor, I ultimately decided to do a GitHub release. However, in the future I was encouraged to look into using CMake or bazel.

NOTE: I won’t mention SBT and Leiningen here because, with all due respect, they are niche build tools. I also won’t discuss Kobalt for the same reason (besides, it’s no longer actively maintained). Additionally, I won’t touch upon Bazel and Buck in this context, mainly because I’m not very familiar with them. If you have insights or comments about these tools, please feel free to share them in the comments 👇

> None of this solves C's only REAL problem (in my opinion) which is the lack of dependency management.

Bazel solves this really nicely, I know some people have strong opinions on it but I cannot recommend it enough

https://bazel.build/