it's speed optimization as the inner code also checks that previous hash value
is not same as new hash value. Essentially those two checks together makes the
compression a little more efficient as it can remember matches further apart.
As far as I remember from my tests, the secondary path was triggered only twice
in very long uncompressed file, but the gain in compression rate was still noticeable.
** Partial merge of this commit, based on a8c94e9f5a3b9d3c62182bcf84e72304a3c1a6e5
Excludes changes to fill_window_sse.c, changes to fill_window_c() in deflate.c
and several unrelated changes in the commit.
* Separate common inlines and macros to deflate_p.h
* Separate deflate_fast related code to deflate_fast.c
* Separate deflate_medium related code to deflate_medium.c
* Separate deflate_slow related code to deflate_slow.c
From: Arjan van de Ven <arjan@linux.intel.com>
As the name suggests, the deflate_medium deflate strategy is designed
to provide an intermediate strategy between deflate_fast and deflate_slow.
After finding two adjacent matches, deflate_medium scans left from
the second match in order to determine whether a better match can be
formed.
Fixes#2