Collapsing the two adjacent calls to outbits saves 32 bytes.
Bringing defl_static.c into lz77.c allows better inlining, saves 24 bytes.
Merge the Outbuf/uzlib_lz77_state_t structs, a minor simplification that
doesn't change code size.
This work was funded through GitHub Sponsors.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
This commit makes the following changes:
- Replace 256-byte reverse-bits-in-byte lookup table with computation.
- Replace length and distance code lookup tables with computation.
- Remove comp_disabled check (it's unused).
- Make the dest_write_cb take the data pointer directly, rather than the
Outbuf.
Saves 500 bytes on PYBV11.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
The compression algorithm implemented in this commit uses much less memory
compared to the standard way of implementing it using a hash table and
large look-back window. In particular the algorithm here doesn't allocate
hash table to store indices into the history of the previously seen text.
Instead it simply does a brute-force-search of the history text to find a
match for the compressor. This is slower (linear search vs hash table
lookup) but with a small enough history (eg 512 bytes) it's not that slow.
And a small history does not impact the compression too much.
To give some more concrete numbers comparing memory use between the
approaches:
- Standard approach: inplace compression, all text to compress must be in
RAM (or at least memory addressable), and then an additional 16k bytes
RAM of hash table pointers, pointing into the text
- The approach in this commit: streaming compression, only a limited amount
of previous text must be in RAM (user selectable, defaults to 512 bytes).
To compress, say, 1k of data, the standard approach requires all that data
to be in RAM, plus an additional 16k of RAM for the hash table pointers.
With this commit, you only need the 1k of data in RAM. Or if it's
streaming from a file (or elsewhere), you could get away with only 256
bytes of RAM for the sliding history and still get very decent compression.
In summary: because compression takes such a large amount of RAM (in the
standard algorithm) and it's not really suitable for microcontrollers, the
approach taken in this commit is to minimise RAM usage as much as possible,
and still have acceptable performance (speed and compression ratio).
Signed-off-by: Damien George <damien@micropython.org>
Jim Mussared