Owen Anderson

Thanks for the analysis. Unfortunately for this example, it's also the case that ZLIB outperforms ZSTD at the default compression level as well. (138KB vs 234KB) It also appears that...

I would expect most of the data in this file to be [LEB128](https://en.wikipedia.org/wiki/LEB128) variable-width integers. I haven't checked, but it's plausible that they're sorted in some way that would cause...

Thanks for that clarification. Looking at the specification and the raw bytes, the data consists of a 12-byte header followed by a sequence of 4-byte little-endian unsigned integers, sorted in...

I am attaching two more examples of other debug info sections that compress worse with ZSTD than with ZLIB at default compression levels. [debug_loclists.bin.gz](https://github.com/facebook/zstd/files/7448255/debug_loclists.bin.gz) - ZSTD 6.4MB vs ZLIB 5.9MB...

It looks like `chrono` does not support `%::z` or `%:::z` format specifiers. I think the right solution is to upstream it there?

Looks like this was just added to `chrono`, actually: https://github.com/chronotope/chrono/commit/5f5410163b6655cd0098530f2c6c44bbcc87d102

> @resistor Nice work here hmm, apart from the linter thing, clippy seems unhappy. > > ``` > ERROR: `cargo clippy`: this argument is passed by value, but not consumed...

> Also there seems to be a bunch of &buf that make the macos build unhappy Should be resolved as well now.

> The coverage implies that we don't have a test for this, is that correct? I suppose so? I'm not familiar with this functionality.

Done to the extent I can figure out how.