Optimize ChecksumIEEE helper

[eapache]

It was calling the fallback update method directly and so wasn't seeing any
optimization. Call updateIEEE instead which includes the optimized path (and
bypasses the unnecessary switch on the table vs just calling Update).

@klauspost
cc @wvanbergen

This explains the confusion we ran into trying to benchmark IBM/sarama#527

[klauspost]

Yes, I just when submitting the CL to the main Go repo.

Well spotted, thanks!

[eapache]

Does that mean this could be built-in to 1.6?

[klauspost]

I cannot see a reason why it shouldn't. You can follow it here:

https://go-review.googlesource.com/#/c/14080/

[klauspost]

@eapache - you might also be interested in github.com/klauspost/compress, I see you use gzip. This version not only uses the faster crc32, but also eliminates all allocations if you re-use/pool the writer, and is generally much faster.

[eapache]

Nobody's complained about gzip yet though :)

Actually, we just use snappy internally, and I suspect most other places do the same so if you have an optimized snappy lib I'm interested :). I suspect they just put gzip in the protocol for completeness's sake, the algorithm isn't really suited for our use case regardless of implementation.

Thanks for all your work on this stuff!