2–3 orders of magnitude more than zlib, for 3-8% improvement in compression quality -- it seems to me that the use cases would be very limited (of the cases listed, basically only PNG? For HTTP, unless it's a static page, won't the server need to re-compress each time before sending data? For gzip or Zip, just use another, deflate-incompatible method for much better results...)
Posted Mar 1, 2013 5:47 UTC (Fri) by rgmoore (subscriber, #75)
[Link]
Even within a dynamic page, there's plenty of content beyond PNGs that is relatively static. Look at the page source for a typical web page, and you'll see perhaps a dozen referenced script sources and stylesheets. Those things are relatively static, so they'd definitely benefit from more efficient compression.
Google releases a better compression algorithm
Posted Mar 1, 2013 10:15 UTC (Fri) by Thue (subscriber, #14277)
[Link]
How about recompressing the Debian archive? Compress once, download a million times. Or Windows updates.
Google releases a better compression algorithm
Posted Mar 1, 2013 10:25 UTC (Fri) by engla (guest, #47454)
[Link]
It's decided by the maintainer of the package. For the upcoming release a lot of packages switched to xz .debs so that the desktop install CDs fit.
Google releases a better compression algorithm
Posted Mar 1, 2013 10:19 UTC (Fri) by Darkmere (subscriber, #53695)
[Link]
I can imagine an offload thread in a caching reverse proxy that would recompress long living objects. Might be doable with a varnish vmod .
Google releases a better compression algorithm
Posted Mar 1, 2013 13:49 UTC (Fri) by huayra (subscriber, #58915)
[Link]
It should be possible, but it would be more interesting doing it in Varnish itself.
CSS and JS minification on a do_minify has been done before, using the same code logic and strategy used for the do_gzip compression support (even keeping the compressed ESI goodness). So replacing gzip or adding this new library and keep gunzip for decompression, could be an idea.