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 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).
- 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
So for this use case, gzip is faster (zstd has only decompression that is fast), compresses better and has way smaller code footprint.
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).
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
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.
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'