Globally turn on/off compression for TPIEs internal use of streams

[thomasmoelhave]

Enabling compression will save temp space, and depending on the device profile (disk bandwidth vs CPU compression bandwidth) also save wall-time. TPIE is now using compression for a number of internal uses of streams, and this makes a lot of sense in many use cases. However in cases where wall-time is paramount and the disk system is very fast (e.g. multiple striped disks in a RAID), compression is not desirable. There should be a way to tell TPIE not to use compression internally, just like you can do the same for file_streams of your own creation.

I suppose the semantics of compression_normal allows for TPIE to make semi-autonomous decisions about this kind of stuff (perhaps guided by the user through some API for tuning when compression is desired or not based on a mix of entropy and performance impact), but in the absence of system for controlling this (skynet?), maybe we should add a global way to change the default compression flag used internally by TPIE?

[Mortal]

This is currently possible by doing the following:

tpie::compressor_thread & compressorThread = tpie::the_compressor_thread();
tpie::compressor_thread_lock lock(compressorThread);
compressorThread.set_preferred_compression(lock, tpie::compression_scheme::none);

This will disable compression for new blocks written to streams opened with compression_normal. This will not enable arbitrary seeking/overwriting since the streams will still be in the compressed format, but it will use the very efficient, patent pending TPIE identity function as the compression method instead of Snappy.

This could probably be encapsulated in a separate function tpie::set_preferred_compression(tpie::compression_scheme), but other than that, I think this functionality is quite sufficient. Do you agree?

[thomasmoelhave]

From my understanding it's solves a slightly different problem, it disables all compression globally? What I wanted was to disable TPIE's own use of compression (in e.g. sorting, stacks and the like) while still maintaining the ability to choose for myself for my own streams. This would be useful in case I want to output the final product to disk and want it to be compressed for archival purposes.
However, that might very well be a relative rare edge case, and your solution does achieve the spirit of what I was asking.