[kazinator]

I integrated gzip into TXR Lisp in 2022. I evaluated all the choices and went with that one because of:

- tiny code size; - widely used standard; - fast compression and decompression.

And it also beat Zstandard on compressing TXR Lisp .tlo files by a non-negligible margin. I can reproduce that today:

  $ zstd -o compiler.tlo.zstd stdlib/compiler.tlo
  stdlib/compiler.tlo  : 25.60%   (250146 =>  64037 bytes, compiler.tlo.zstd)
  $ gzip -c > compiler.tlo.gzip stdlib/compiler.tlo
  $ ls -l compiler.tlo.*
  -rw-rw-r-- 1 kaz kaz 60455 Jul  8 21:17 compiler.tlo.gzip
  -rw-rw-r-- 1 kaz kaz 64037 Jul  8 17:43 compiler.tlo.zstd

The .gzip file is 0.944 as large as the .zstd file.

So for this use case, gzip is faster (zstd has only decompression that is fast), compresses better and has way smaller code footprint.

[jonas21]

zstd uses a fairly low compression level by default. If you run with `zstd -19 -o compiler.tlo.zstd stdlib/compiler.tlo` you will probably get much better compression than gzip, even at its highest setting.

That said, the tiny code footprint of gzip can be a real benefit. And you can usually count on gzip being available as a system library on whatever platform you're targeting, while that's often not the case for zstd (on iOS, for example).

[kazinator]

Additional datapoints:

Tne Zopfli gzip-compatible compressor gets the file down to 54343. But zstd with level -19 beats that:

  -rw-rw-r-- 1 kaz kaz 54373 Jul  8 22:59 compiler.tlo.zopfli
  -rw-rw-r-- 1 kaz kaz 50102 Jul  8 17:43 compiler.tlo.zstd.19

I have no idea which is more CPU/memory intensive.

For applications in which compression speed is not important (data is being prepared once to be decompressed many times), if you want the best compression and stick with gzip, Zopfli is the ticket.

[attentive]

Try lzip. It's about 10 times faster than zopfli though it's not gzip compatible. And it beats zstd -19 on compression.

[Quekid5]

I believe the default compression setting for the zstd command is biased towards speed -- maybe try -9, -13 or even -22 (max, which should probably be fine for such a small file).

Not that it matters when the file is so small in the first place... I'm just saying you should be sure what you're 'benchmarking'