5 ms·
Gzip is fine for lots of tasks. It's not the most efficient compressor, either by space or speed. But it has a million implementations that all work well toget
by nrclark 4y ago
Gzip is fine for lots of tasks.
It's not the most efficient compressor, either by space or speed. But it has a million implementations that all work well together.
If you just need "good enough" compression with no fuss, gzip is still an excellent choice.
- ericbarrett 4y agoI agree with this, even as a long-time zstd user both personally and professionally. The fact is nearly every app, widget, API, and even CPU can encode and decode gzip. Sometimes you need to make the prosaic choice.
- tiagod 4y agoI feel like zstd, if nothing better shows up, will become a lot like gzip in the long run
- somat 4y agofor a long time the status quo was that while there were better compressions engines (bzip2 comes to mind) none were faster than gzip. I actually preferred gzip for a lot of tasks because it was faster to compress and decompress. I saw a comment that zstd is actually faster than gzip so I guess that consideration no longer holds.
- jeffbee 4y agoMost things are faster than gzip, and many of those things have smaller outputs as well. Brotli at level 2 produces the same-sized archive with this input, in just 3.4s. Gzip even at level 1, with a 10% larger archive, still needs 6.5s. zstd, at level 1, produces the same size as gzip -1, in 1 second! zstd, cranked up to 9, makes a 20% smaller archive in 7 seconds, less than half the time of gzip -6.