logoalt Hacker News

Hellishly Slow Level 13 Deflate Compression

88 pointsby zX41ZdbWlast Monday at 6:17 PM25 commentsview on HN

Comments

jboshtoday at 4:31 AM

I love it. So much in computers is trade offs and this was a fun read exploring it.

It would be interesting to see some economics of what 8,000% increase in encoding time takes to make that money back in terms of storage or bandwidth. I also wonder how brotli/lzma would compare here. Are there some obscene modes on those that had similar results?

show 4 replies
jedbrooketoday at 7:05 AM

reminds me of the x264 “placebo” encoder setting

https://trac.ffmpeg.org/wiki/Encode/H.264#FAQ

tobijdctoday at 5:29 AM

There is also zopfli and it's decadent ECT that allow for more extreme tradeoffs.

blobberstoday at 7:03 AM

As someone currently exploring grid searches of encodings + compressor combos, and currently looking at neural compressors that reduce size almost half that of a traditional compressor yet take order from ms -> minutes to operate in either direction, I appreciate a good compression post!

userbinatortoday at 6:00 AM

It's interesting to see just how far Deflate can be taken, and to know that even after decades there is still some (admittedly tiny) room for improvement. Optimal LZ is well-known, and so is static Huffman, but their combination creates some additional inefficiencies(opportunities).

...and of course it's written by someone with a Russian name, and has that characteristic style common to many other articles about data compression.

pellatoday at 8:24 AM

OpenZL is the future: https://openzl.org/

  "OpenZL delivers high compression ratios while preserving high speed, a level of performance that is out of reach for generic compressors. OpenZL takes a description of your data and builds from it a specialized compressor optimized for your specific format."
Someonetoday at 5:58 AM

So, what’s the effect on memory usage?

And for decompression, the effect on memory usage and timings?

show 1 reply