Are people really using gzip in 2025 for new projects?
Zstd has been widely available for a long time. Debian, which is pretty conservative with new software, has shipped zstd since at least stretch (released 2017).
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).
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.
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'
- 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:
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.