snappy's tester cheats a little in snappy's favor about snappy HOT 5 CLOSED

Hi,

I looked a bit into this, and you're right that it's not equal between the 
different compression algorithms. This is most likely because Compress() is 
used both for the comparative benchmarks and for the ones within Snappy itself; 
and for the latter, we don't want the performance numbers to be polluted with 
whatever malloc is in use. (I'm actually surprised it matters so much, but I'd 
guess it depends on your malloc.)

I think the right solution is actually the opposite of what you're proposing, 
though; remove the resize() calls from the other algorithms, not add them to 
Snappy. This would require a bit more logic on the outside, though (it would 
need to resize the buffer to something that gives sense for all the algorithms 
in use).

I don't particularly care which way the tester makes sure libraries have equal 
conditions, just that it does.

There is code to that effect:
      // Pre-grow the output buffer so we don't measure stupid string
      // append time
      compressed[b].resize(block_size * 2);

So the buffer should be large enough to satisfy any sane algorithm (and indeed 
LZO works with the resize commands removed). I don't have the other libraries 
besides zlib and lzo to test with, and zlib decompression for example doesn't 
work with just the resize command removed, so I hesitate to touch code I can't 
even test.

QuickLZ needs 36000 scratch bytes, though, so perhaps max(block_size * 2, 
block_size + 36000)?

Why can't you test the other libraries? They are all freely available.

Fixed in r24.