Configuring a Deflater
On the previous page, we saw how to use a Deflater to compress data in Java (and how to read the compressed data back in again). We mentioned that the
reason for explicitly constructing the Deflater object separately to the
DeflaterOutputStream is that in this way, the Deflater can be
configured. The main two parameters that we can configure are as follows:
- the compression level defines how much of a tradeoff
we are prepared to make between speed of compression and size of compressed output;
- the compression strategy allows us to effectively switch out
part of the deflater algorithm, which may be appropriate in some circumstances
where we are wrapping the deflater around our own compression/transform mechanism.
In our discussion of how the Deflater
works, we saw that a key part is dictionary compression.
In this type of compression, the compressor looks for previously-occurring sequences
that are the same as the sequence about to be encoded.
When constructing a Deflater, you can specify a compression level
value, from 1 to 9.
The compression level, roughly speaking, defines how
rigorously the compressor looks to find the longest string possible.
As a general rule of thumb:
- Compressing at the maximum level (9) requires around twice as much
processor time as compressing at the minimum level (1);
- For typical textual input, compressing at the maximum as opposed to the
minimum level adds around 5% to the compression ratio.
You have to decide whether, for your application, the extra processor time is worth
the extra few per cent of compression.
Generally speaking, it will not be necessary to change the compression strategy.
However, in certain advanced cases, you can actually improve compression by transforming
your data so that Huffman encoding works better on it.
In such cases, we'll see that
explicitly specifying the FILTERED or HUFFMAN_ONLY strategy can be beneficial.