gzip benchmarks for comparison?

[bmatsuo]

@mreiferson do you have interest in adding benchmarks using gzip for direct comparison (using the same data)?

I was just too curious so I wrote some (branched off #6). Gzip is significantly slower at everything except decoding highly-compressible and incompressible data where it is approximately the same speed. Maybe that was to be expected. I didn't expected it with my naivety about the algorithms differences. Let me know if you want them in the repo and I'll open a PR after buffering is merged.

PASS
BenchmarkWriterManpage            50000                                  49038       ns/op  86.20    MB/s
BenchmarkBufferedWriterManpage    50000                                  73349       ns/op  57.63    MB/s
BenchmarkGZIPWriterManpage        5000                                   543117      ns/op  7.78     MB/s
BenchmarkWriterJSON               5000                                   554545      ns/op  283.76   MB/s
BenchmarkBufferedWriterJSON       5000                                   552542      ns/op  284.79   MB/s
BenchmarkGZIPWriterJSON           500                                    3743897     ns/op  42.03    MB/s
BenchmarkWriterRandom             5                                      259614227   ns/op  40.39    MB/s
BenchmarkBufferedWriterRandom     5                                      256428245   ns/op  40.89    MB/s
BenchmarkGZIPWriterRandom         1                                      1203534689  ns/op  8.71     MB/s
BenchmarkWriterConstant           100                                    19672959    ns/op  533.00   MB/s
BenchmarkBufferedWriterConstant   100                                    19384469    ns/op  540.94   MB/s
BenchmarkGZIPWriterConstant       20                                     118393736   ns/op  88.57    MB/s
BenchmarkReaderManpage            100000                                 24475       ns/op  104.18   MB/s
BenchmarkReaderManpage_buffered   100000                                 25946       ns/op  98.28    MB/s
BenchmarkGZIPReaderManpage        100000                                 24962       ns/op  102.15   MB/s
BenchmarkReaderJSON               5000                                   398743      ns/op  61.26    MB/s
BenchmarkReaderJSON_buffered      5000                                   438311      ns/op  51.51    MB/s
BenchmarkGZIPReaderJSON           5000                                   417980      ns/op  54.02    MB/s
BenchmarkReaderRandom             500                                    3206398     ns/op  3271.06  MB/s
BenchmarkReaderRandom_buffered    500                                    3140224     ns/op  3339.59  MB/s
BenchmarkGZIPReaderRandom         500                                    3121361     ns/op  3359.77  MB/s
BenchmarkReaderConstant           100                                    19830975    ns/op  25.00    MB/s
BenchmarkReaderConstant_buffered  100                                    20004430    ns/op  24.68    MB/s
BenchmarkGZIPReaderConstant       100                                    19796565    ns/op  24.93    MB/s
ok                                github.com/mreiferson/go-snappystream  68.468s

[mreiferson]

I guess it's fine for those that might be interested, this is more credit to snappy-go and the algorithm than this implementation of the streaming format, though.

[bmatsuo]

this is more credit to snappy-go and the algorithm than this implementation of the streaming format, though.

I agree completely. The thing that makes me think it deserves to be here is that the snappy-go:gzip comparison cannot be made directly using identical input data (block compression vs streaming). That and I think gophers would be inherently curious if they are hearing about snappy for the first time.

[mreiferson]

yea, it's fine...

[mreiferson]

you wanna bring these in for posterity?

[bmatsuo]

I waffled on this a little. It may be better as a blog post or a gist or something. Possibly with more compression algorithms involved. There could just be a link to those results from README.md

The benchmarks take significant time. I tried to add a flag (i.e. go test -bench=. -compare-gzip) so the benchmarks skip when not desired, which is most of the time. But b.Skip() just makes the output look terrible (I hoped it would only look gross when -v was supplied). I'm not sure how it would play with benchcmp either.

What do you think?

[mreiferson]

yea, let's just move on... closing