[Feature]: Use parallel gzip compression as implemented in pigz

[ghuls]

Use parallel gzip compression as implemented in pigz.

https://zlib.net/pigz/pigz.pdf

Pigz compresses using threads to make use of multiple processors and cores. The input is bro- ken up into 128 KB chunks with each compressed in parallel. The individual check value for each chunk is also calculated in parallel. The compressed data is written in order to the output, and a combined check value is calculated from the individual check values. The compressed data for mat generated is in the gzip, zlib, or single-entry zip for mat using the deflate compression method. The compression produces partial raw deflate streams which are concatenated by a single write thread and wrapped with the appropriate header and trailer, w here the trailer contains the combined check value. Each partial raw deflate stream is terminated by an empty stored block ( using the Z_SYNC_FLUSH option of zlib), in order to end that partial bit stream at a byte boundary. That allows the partial streams to be concatenated simply as sequences of bytes. This adds a very small four to five byte overhead to the output for each input chunk. The default input block size is 1 28K, but can be changed with the -b option. The number of com- press threads is set by default to the number of online processors, which can be changed using the -p option. Specifying -p 1 avoids the use of threads entirely. The input blocks, while compressed independently, have the last 32K of the previous block loaded as a preset dictionary to preserve t he compression effectiveness of deflating in a single thread. This can be turned off using the -i or --independent option, so that the blocks can be decompressed independently for partial error recovery or f or random access. This also inserts an extra empty block to flag independent blocks by prefacing each with the nine-byte sequence (in hex): 00 00 FF FF 00 00 00 FF FF. Decompression can’t be parallelized, at least not without specially prepared deflate streams for that purpose. A s a result, pigz uses a single thread (the main thread) for decompression, but will create three other threads for reading, writing, and check calculation, which can speed up decompression under some circumstances..

[sstadick]

Hi! Where were you thinking this might fit into rust-lapper? I have another crate that does provide exactly that: https://github.com/sstadick/gzp

[ghuls]

@sstadick Sorry, it was meant for the gzp repo. Do you plan to add continuous dictionary compression in the future?

[sstadick]

I don't plan on adding that myself anytime soon. The best that I can tell flate2 doesn't expose enough internals to to use it to do that. If I could figure out how to do it with flate2 I certainly would though.

[sstadick]

I'm going to close this here, but feel free to reopen it over in gzp. I think this is a reasonable feature request over there even if it's not coming in the short term. Longer term I foresee having to dig more into the internals of flate2 anyways, to the point that this will become possible.