[blank_state]

The formatting is just so bad, let's retry it here :

   | Algo      | compressed size | compression speed | decompression speed |
   | --------- | --------------- | ----------------- | ------------------- |
   | brotli -2 |  36223          |  220 MB/s         |  670 MB/s           |
   | zstd -1   |  36655          |  480 MB/          | 1400 MB/s           |
   | brotli -1 |  38292          |  360 MB/s         |  650 MB/s           |
   | brotli -0 |  41141          |  560 MB/s         |  610 MB/s           |

[JyrkiAlakuijala]

If you read your own results with care you will notice that your results also show that fastest brotli is faster than fastest zstd. Your results also show that brotli compresses more than zstd at higher settings, even if you turn off the static dictionary of brotli.

If you are interested at zstd 0.7.1 -22, you can reach the same compression density with brotli 0.4.0 at quality setting -7 (at least for this file with the static dictionary). Then you are comparing a brotli's compression speed of 57 MB/s to zstd's 4.01 MB/s. Brotli is 14x faster at this compression density.

For decompress-once roundtrip at this density, brotli achieves 53 MB/s, and zstd 4 MB/s. Brotli's roundtrip is 13x faster.

In decompression brotli is 2x slower on Intel, but decompression times at 800+ MB/s are going to be negligible in most use (think < 1 % of cycles in your datacenter), if the data is parsed/processed somehow afterwards.

Brotli's entropy encoding is simpler (no 64-bit operations), and because of this on 32 bit arm the decompression speeds of zstd and brotli are about the same.

I acknowledge that there can be use cases where zstd 0.7.1 can be favorable to brotli 0.4.0 -- particularly those where a 32+ MB file is compressed at once and the 150-500 MB/s compression speed range, but even this simple compression test shows that brotli can compress significantly (5-10+ %) more with the higher quality settings.