Quick Benchmark: Gzip vs Bzip2 vs LZMA vs XZ vs LZ4 vs LZO

EDIT: Add zstd

Contents

 [hide] 

• 1 Selected archives
• 2 Test conditions
• 3 The file test results
  • 3.1 Compressed file size in bytes
  • 3.2 Compression ratio
  • 3.3 Compression time
  • 3.4 Decompression time
  • 3.5 Memory requirements on compression
  • 3.6 Memory requirements on decompression
• 4 Stream test
  • 4.1 Time to compress
  • 4.2 Time to decompress
  • 4.3 Memory used
  • 4.4 Compression ratio
    • 4.4.1 With the benchmark application
• 5 Graphics
• 6 Quick benchmark on ARM64

Selected archives

I have selected:

• Source of the kernel to test source compression
• Stream protocol with flush

Test conditions

Tests were run on a desktop:

• Intel Core i5 CPU 750 at 2.67GHz
• 8GB of DDR3 memory
• tmpfs as ram disk is used
• Linux kernel 3.3.2, gentoo amd64
• CFLAGS: -pipe -O2 -g -floop-block -floop-interchange -fgraphite
• bzip2-1.0.6-r3, xz-utils-5.0.3, gzip-1.4

Only normal mode will be tested firstly.

The file test results

Note: The first column with numbers 1..9 indicates the compression setting passed to gzip, bzip2 and lzmash (e.g. “gzip -9”).

Tarball mode from linux-3.3, original size: 466083840 (445M)

Compressed file size in bytes

Compression ratio

Compression time

• gzip -1 vs lz4 -1 on x86: lz4 6.2x more fast
• gzip -1 vs lz4 -1 on ARM: lz4 3.6x more fast

Decompression time

Memory requirements on compression

• Note: lz4 it’s the program using this size, the code for internal lz4 use very less memory

Memory requirements on decompression

• Note: lz4 it’s the program using this size, the code for internal lz4 use very less memory

Cli used for -1 compression:

• time gzip -1 linux-3.3.tar;du -ksh linux-3.3.tar*;ls -l linux-3.3.tar*;time gunzip linux-3.3.tar*
• time bzip2 -1 linux-3.3.tar;du -ksh linux-3.3.tar*;ls -l linux-3.3.tar*;time bunzip2 linux-3.3.tar.bz2
• time lzma -1 linux-3.3.tar;du -ksh linux-3.3.tar*;ls -l linux-3.3.tar*;read PAUSe;time unlzma linux-3.3.tar*
• time lzma -e -1 linux-3.3.tar;du -ksh linux-3.3.tar*;ls -l linux-3.3.tar*;read PAUSe;time unlzma linux-3.3.tar*
• time xz -1 linux-3.3.tar;du -ksh linux-3.3.tar*;ls -l linux-3.3.tar*;read PAUSe;time unxz linux-3.3.tar*
• time xz -e -1 linux-3.3.tar;du -ksh linux-3.3.tar*;ls -l linux-3.3.tar*;read PAUSe;time unxz linux-3.3.tar*
• time /home/user/lz4-read-only/lz4demo64 -c0 linux-3.3.tar linux-3.3.tar.lz4;du -ksh linux-3.3.tar*;ls -l linux-3.3.tar*;read PAUSe;time /home/user/lz4-read-only/lz4demo64 -d linux-3.3.tar.lz4 linux-3.3.tar;rm linux-3.3.tar.*
• time lzop -1 linux-3.3.tar;rm linux-3.3.tar;du -ksh linux-3.3.tar*;ls -l linux-3.3.tar*;read PAUSe;time lzop -d linux-3.3.tar*;rm linux-3.3.tar.*

Stream test

Time to compress

Time to decompress

Messured with:

timespec tstart,tstop;
clock_gettime(CLOCK_REALTIME, &tstart);
//compression/decompression
clock_gettime(CLOCK_REALTIME, &tstop);
compressionTime+=((quint64)tstop.tv_sec * 1000000LL + (quint64)tstop.tv_nsec / 1000LL)-((quint64)tstart.tv_sec * 1000000LL + (quint64)tstart.tv_nsec / 1000LL);

Memory used

The socket is always used as full duplex, then it’s compression + decompression memory.

Compression ratio

It’s transferred size/raw size (lower is better)

With the benchmark application

Uploaded at: https://github.com/alphaonex86/debug-devel/tree/master/QTcpCompressionBenchmark

The most over-head of small packet (3Bytes) is drop by high compression with zlib/gzip for the big packet.

Graphics

Quick benchmark on ARM64

A quick benchmark on ARM64 (odroid, Cortex A53), on kernel Image (12MB), use default compression level (-6) because no way to configure the compression level of btrfs

The speed is on compressed stream, mean the hdd.