Hi,

I work at Google, and I've been working on the Snappy open-sourcing. First of all, let me state that when doing our benchmarks, we were definitely comparing against the latest public version (1.5.0) of QuickLZ. I'm having problems reproducing your benchmark results; could you provide some more details about the exact settings, compiler version, architecture etc.? I can't even get all of the compression ratios to match up exactly with the ones I'm seeing, so there must be some sort of difference between the setups. Are you perchance running Snappy with assertions enabled? (The microbenchmark will complain if you do, so it's easy to check.)

For what it's worth, I ran the QuickLZ test suite on my own machine (you can see the exact testing environment below), and got quite different results:

  qlz-testsuite/flower.bmp                 :
  QUICKLZ: [b 1M] bytes 5922816 -> 5087471 85.9%  comp 132.4 MB/s  uncomp 140.8 MB/s
  SNAPPY: [b 4M] bytes 5922816 -> 5369439 90.7%  comp 180.6 MB/s  uncomp 484.0 MB/s
  qlz-testsuite/gdb.exe                    :
  QUICKLZ: [b 1M] bytes 8872609 -> 4074990 45.9%  comp 177.4 MB/s  uncomp 213.3 MB/s
  SNAPPY: [b 4M] bytes 8872609 -> 4530851 51.1%  comp 224.7 MB/s  uncomp 468.7 MB/s
  qlz-testsuite/northwind.mdf              :
  QUICKLZ: [b 1M] bytes 2752512 -> 628607 22.8%  comp 291.3 MB/s  uncomp 409.6 MB/s
  SNAPPY: [b 4M] bytes 2752512 -> 726437 26.4%  comp 456.6 MB/s  uncomp 790.1 MB/s
  qlz-testsuite/plaintext.txt              :
  QUICKLZ: [b 1M] bytes 2899483 -> 1436466 49.5%  comp 155.4 MB/s  uncomp 182.7 MB/s
  SNAPPY: [b 4M] bytes 2899483 -> 1629408 56.2%  comp 195.2 MB/s  uncomp 487.5 MB/s
  qlz-testsuite/proteins.txt               :
  QUICKLZ: [b 1M] bytes 7254685 -> 2600129 35.8%  comp 218.2 MB/s  uncomp 261.2 MB/s
  SNAPPY: [b 4M] bytes 7254685 -> 2934406 40.4%  comp 269.4 MB/s  uncomp 556.9 MB/s

  Average compression ratio (geometric mean, lower is better): QuickLZ 43.7%, Snappy 48.9%.
  Average compression speed (harmonic mean): QuickLZ 180.9 MB/s, Snappy 238.0 MB/s.
  Average decompresion speed (harmonic mean): QuickLZ 212.5 MB/s, Snappy 536.9 MB/s.

In addition, there's one nearly-incompressible file listed on the same page, which I also ran on (it's not included in the averages above):

  qlz-testsuite/NotTheMusic.mp4            :
  QUICKLZ: [b 1M] bytes 9832475 -> 9832565 100.0%  comp 289.3 MB/s  uncomp 2815.9 MB/s
  SNAPPY: [b 4M] bytes 9832475 -> 9485433 96.5%  comp 1308.4 MB/s  uncomp 2477.1 MB/s

This is on a Nehalem 2.27GHz, running Debian GNU/Linux 6.0 in 64-bit mode, GCC version 4.4.5, with flags -O2 -g -DNDEBUG for both Snappy (1.0.0) and QuickLZ (1.5.0), running snappy_unittest to compare. QuickLZ was left at the default settings, ie. the files were exactly as downloaded from http://www.quicklz.com/quicklz.[ch] as of today. In particular, this means QuickLZ was running in unsafe mode, which means it could crash on corrupted compressed input. (Safe mode, which is comparable to how Snappy runs, is, according to http://www.quicklz.com/download.html, 15–20% slower at decompression, so the difference would be bigger.)

Exact benchmark results will, as always, vary with differing compiler, set of flags, CPU, and data set. The average numbers from this benchmark, however, show QuickLZ 1.5.0 (in unsafe mode) compressing about 11% more densely than Snappy 1.0.0 does, but Snappy compressing about 32% faster and decompressing about 153% faster (ie., about 2.53 times as fast).

/* Steinar */