Benchmark File Compression Tools Safely

Compression choices should be based on your own data, recovery-time objectives, and available CPU. A benchmark copied from another system can be misleading because text, database exports, binaries, and already-compressed files behave very differently.

Benchmark without changing the source file

The following commands write new compressed files and leave sample.dat untouched:

/usr/bin/time -f 'gzip elapsed=%e cpu=%P'  gzip -c sample.dat > sample.dat.gz
/usr/bin/time -f 'bzip2 elapsed=%e cpu=%P' bzip2 -c sample.dat > sample.dat.bz2
/usr/bin/time -f 'xz elapsed=%e cpu=%P'    xz -c sample.dat > sample.dat.xz
/usr/bin/time -f 'zstd elapsed=%e cpu=%P'  zstd -c sample.dat > sample.dat.zst

ls -lh sample.dat sample.dat.gz sample.dat.bz2 sample.dat.xz sample.dat.zst

Not every system includes every tool. Install software only from your operating system’s trusted package source, and record the exact tool version and options with the result.

Verify that every result is recoverable

sha256sum sample.dat
gzip  -dc sample.dat.gz  | sha256sum
bzip2 -dc sample.dat.bz2 | sha256sum
xz    -dc sample.dat.xz  | sha256sum
zstd  -dc sample.dat.zst | sha256sum

All hashes must match. A small output file is useless if it cannot be restored reliably.

What to record

• Input type and size
• Compressed size and compression ratio
• Compression and decompression elapsed time
• CPU and peak memory use
• Tool version, command options, and hardware

For backups, test decompression speed as carefully as compression speed. Also test several representative files instead of one unusually compressible sample. Keep the original benchmark data or a reproducible generator so later tests are comparable.

The legacy article’s copied script and corrupted results have been removed. This version focuses on a repeatable, non-destructive method that can be used on current Unix-like systems.