Performance improvements about deflate-rs HOT 1 OPEN

So the main point where the current implementation (outside of RLE mode) spends much time (according to operf) is the comparison after loading the next value from the hash chain in the matching function:
https://github.com/oyvindln/deflate-rs/blob/dd923fb9950b6fce37cec9ed6ab617a036c559b8/src/matching.rs#L103

Maybe this is the cpu stalling waiting for data or something.

Current plans for improvements that may or may not help:

• Avoid creating an the extra temporary huffman code length table.
• Avoid using a temporary heap buffer in in_place_lengths.
• Change the match function to behave more like miniz:
  • divide max iterations by 3, do 3 checks per iteration, jump to next iteration on a match
    • This didn't seem to make any difference to performance
• Implement a longest_match function using this algorithm to possibly cut down on hash chain iterations:http://www.gildor.org/en/projects/zlib
• Avoid bounds checks in various functions (huffman table length/distance lookups, hash chain, huffman length generation and others)
• Check for faster CRC generators (current used library seems to be abandoned/inactive with some PRs with improvements)
• Consider using threads for some operations
• Avoid buffering input when it's not needed (e.g for the simple functions (deflate_*) and if write_all is called with a very long buffer.)
  • Specialisation is unstable, so we might want to make a VecEncoder or something similar instead for now
• Avoid buffering output when using a writer where writing is "guaranteed"(excluding OOM) to succeed, e.g Vec.
• Try to heap-allocate buffers close together in memory. Don't think it's currently doable in an easy way in current stable rust without blowing up the stack (box syntax is unstable, but even that may not work in debug mode).

from deflate-rs.