Compress a data stream provided as a lazy ByteString.

There are no expected error conditions. All input data streams are valid. It is possible for unexpected errors to occur, such as running out of memory, or finding the wrong version of the bz2 C library; these are thrown as exceptions.

Decompress a data stream provided as a lazy ByteString.

It will throw an exception if any error is encountered in the input data. If you need more control over error handling then use one of the incremental versions, decompressST or decompressIO.

The unfolding of the compression process, where you provide a sequence of uncompressed data chunks as input and receive a sequence of compressed data chunks as output. The process is incremental, in that the demand for input and provision of output are interleaved.

Incremental compression in the ST monad. Using ST makes it possible to write pure lazy functions while making use of incremental compression.

Chunk size must fit into CUInt.

Incremental compression in the IO monad.

Chunk size must fit into CUInt.

A fold over the CompressStream in the given monad.

One way to look at this is that it runs the stream, using callback functions for the three stream events.

A variant on foldCompressStream that is pure rather than operating in a monad and where the input is provided by a lazy ByteString. So we only have to deal with the output and end parts, making it just like a foldr on a list of output chunks.

For example:

toChunks = foldCompressStreamWithInput (:) []

The unfolding of the decompression process, where you provide a sequence of compressed data chunks as input and receive a sequence of uncompressed data chunks as output. The process is incremental, in that the demand for input and provision of output are interleaved.

The possible error cases when decompressing a stream.

This can be shown to give a human readable error message.

Since: 0.5.3.0

Incremental decompression in the ST monad. Using ST makes it possible to write pure lazy functions while making use of incremental decompression.

Chunk size must fit into CUInt.

Incremental decompression in the IO monad.

Chunk size must fit into CUInt.

A fold over the DecompressStream in the given monad.

One way to look at this is that it runs the stream, using callback functions for the four stream events.

A variant on foldDecompressStream that is pure rather than operating in a monad and where the input is provided by a lazy ByteString. So we only have to deal with the output, end and error parts, making it like a foldr on a list of output chunks.

For example:

toChunks params = foldDecompressStreamWithInput (:) (const []) throw (decompressST params)

or

import qualified Data.ByteString.Lazy          as L
import qualified Data.ByteString.Lazy.Internal as L

decompressWith params = foldDecompressStreamWithInput (L.chunk) (const L.empty) throw (decompressST params)

The full set of parameters for compression. The defaults are defaultCompressParams.

The compressBufferSize is the size of the first output buffer containing the compressed data. If you know an approximate upper bound on the size of the compressed data then setting this parameter can save memory. The default compression output buffer size is 16k. If your estimate is wrong it does not matter too much, the default buffer size will be used for the remaining chunks.

The default set of parameters for compression. This is typically used with the compressWith function with specific parameters overridden.

The full set of parameters for decompression. The defaults are defaultDecompressParams.

The decompressBufferSize is the size of the first output buffer, containing the uncompressed data. If you know an exact or approximate upper bound on the size of the decompressed data then setting this parameter can save memory. The default decompression output buffer size is 32k. If your estimate is wrong it does not matter too much, the default buffer size will be used for the remaining chunks.

One particular use case for setting the decompressBufferSize is if you know the exact size of the decompressed data and want to produce a strict ByteString. The compression and decompression functions use lazy ByteStrings but if you set the decompressBufferSize correctly then you can generate a lazy ByteString with exactly one chunk, which can be converted to a strict ByteString in O(1) time using concat . toChunks.

The default set of parameters for decompression. This is typically used with the compressWith function with specific parameters overridden.

The block size affects both the compression ratio achieved, and the amount of memory needed for compression and decompression.

BlockSize 1 through BlockSize 9 specify the block size to be 100,000 bytes through 900,000 bytes respectively. The default is to use the maximum block size.

Larger block sizes give rapidly diminishing marginal returns. Most of the compression comes from the first two or three hundred k of block size, a fact worth bearing in mind when using bzip2 on small machines. It is also important to appreciate that the decompression memory requirement is set at compression time by the choice of block size.

• In general, try and use the largest block size memory constraints allow, since that maximises the compression achieved.
• Compression and decompression speed are virtually unaffected by block size.

Another significant point applies to files which fit in a single block - that means most files you'd encounter using a large block size. The amount of real memory touched is proportional to the size of the file, since the file is smaller than a block. For example, compressing a file 20,000 bytes long with the flag BlockSize 9 will cause the compressor to allocate around 7600k of memory, but only touch 400k + 20000 * 8 = 560 kbytes of it. Similarly, the decompressor will allocate 3700k but only touch 100k + 20000 * 4 = 180 kbytes.

The WorkFactor parameter controls how the compression phase behaves when presented with worst case, highly repetitive, input data. If compression runs into difficulties caused by repetitive data, the library switches from the standard sorting algorithm to a fallback algorithm. The fallback is slower than the standard algorithm by perhaps a factor of three, but always behaves reasonably, no matter how bad the input.

Lower values of WorkFactor reduce the amount of effort the standard algorithm will expend before resorting to the fallback. You should set this parameter carefully; too low, and many inputs will be handled by the fallback algorithm and so compress rather slowly, too high, and your average-to-worst case compression times can become very large. The default value of 30 gives reasonable behaviour over a wide range of circumstances.

• Note that the compressed output generated is the same regardless of whether or not the fallback algorithm is used.

For files compressed with the default 900k block size, decompression will require about 3700k to decompress. To support decompression of any file in less than 4Mb there is the option to decompress using approximately half this amount of memory, about 2300k. Decompression speed is also halved, so you should use this option only where necessary.