use a buffer for state_history's boost iostreams de/compression pipeline improving performance

[spoonincode]

Without a buffer size passed to these components in the de/compression pipeline, boost iostreams seems to send data through byte-by-byte. Adding a buffer improves performance nearly double for populating initial state. In leap 5.0: ~12m30s, after #33: ~6m20s, this PR: ~3m15s.

Certainly open to being schooled on how to better utilize boost iostreams if I missed a better way; this very pessimistic default buffering behavior was surprising.

[heifner]

The zlib de/compressor of transaction.cpp could likely benefit from a buffer as well.

[spoonincode]

fwiw I looked at this a little more and the reason buffering is being disabled is because the counter indicates,

spring/libraries/state_history/include/eosio/state_history/log.hpp

Line 254 in 9295331

bio::optimally_buffered_tag

which means this gets called,

spring/libraries/state_history/include/eosio/state_history/log.hpp

Line 260 in 9295331

std::streamsize optimal_buffer_size() const { return 0; }

which effectively disables buffering (I guess just going in to the counter?). Otherwise filters should have a default buffer of 128 bytes, and devices 4K. It's quite possible for ship's large data structures the bigger 64KB buffer is healthier than 128/4K anyways though.

[spoonincode]

Since I've already tested these changes, going to go ahead and merge as-is even though it seems like the lack of buffering by default is due to improper counter implementation.

The zlib de/compressor of transaction.cpp could likely benefit from a buffer as well.

It would be curious to benchmark it now that it appears that usage would have a (small?) buffer by default

[ericpassmore]

Note:start
group: STABILITY
category: PERFORMACE
summary: Improve state history performance by using a buffer for the de/compression pipeline.
Note:end