3 ms·
EDIT: Something weird is going on here. When compressing zstd in parallel it produces the garbage results seen here, but when compressing on a single core, it p
by mort96 9mo ago
EDIT: Something weird is going on here. When compressing zstd in parallel it produces the garbage results seen here, but when compressing on a single core, it produces result competitive with Brotli (37M). See: https://news.ycombinator.com/item?id=46723158 https://news.ycombinator.com/item?id=46723158
I did my own testing where Brotli also ended up better than ZSTD: https://news.ycombinator.com/item?id=46722044 https://news.ycombinator.com/item?id=46722044
Results by compression type across 55 PDFs:
+------+------+-----+------+--------+
| none | zstd | xz | gzip | brotli |
+------|------|-----|------|--------|
| 47M | 45M | 39M | 38M | 37M |
+------+------+-----+------+--------+
- mort96 9mo agoTurns out that these numbers are caused by APFS weirdness. I used 'du' to get them which reports the size on disk, which is weirdly bloated for some reason when compressing in parallel. I should've used 'du -A', which reports the apparent size. Here's a table with the correct sizes, reported by 'du -A' (which shows the apparent size): +---------+---------+--------+--------+--------+ | none | zstd | xz | gzip | brotli | +---------|---------|--------|--------|--------| | 47.81M | 37.92M | 37.96M | 38.80M | 37.06M | +---------+---------+--------+--------+--------+ These numbers are much more impressive. Still, Brotli has a slight edge.
- tracker1 9mo agoWorth considering the compress/decompress overhead, which is also lower in brotli than zstd from my understanding. Also, worth testing zopfli since it's decompression is gzip compatible.