[Zlib-devel] Google's version of zlib code
Frédéric Kayser
f.kayser at free.fr
Sun Mar 3 14:28:30 EST 2013
LZMA is a pretty good but perhaps a tad to slow to compress and even decompress, Charles Bloom did some interesting comparisons:
http://cbloomrants.blogspot.fr/2012/09/09-15-12-some-compression-comparison.html
I'll have to check some threads on http://encode.ru but it seems that some LZMA features are practically never used, and anyway it should be seriously tamed from a memory usage point of view other wise it could be a real memory bomb for small devices, LZMA2 already restricts some of the options that can be used.
Regards
--
Frédéric Kayser
Le 3 mars 2013 à 19:13, Greg Roelofs a écrit :
> Mark Adler wrote:
>
>> On Mar 2, 2013, at 7:54 AM, Nelson H. F. Beebe <beebe at math.utah.edu> wrote:
>>> Google publishes Zopfli as open-source compression algorithm to speed up Web download
>>> Compression is about 100 times slower than conventional methods but compresses about 5% better,
>
>> That's cool, but it seems like an awful lot of effort for a small improvement.
>
> Agreed. Other than a tiny, tiny handful of purveyors of static content--
> someone like Akamai, perhaps, except they're probably contractually bound
> not to screw with it and probably don't have the compute resources to waste
> on it anyway--I can't imagine too many entities that would find this useful,
> Google included.
>
>> Perhaps it's time to add a better compression method to HTTP's accept-encoding.
>
> LZMA seems like an obvious candidate. There's probably room for a QuickLZ or
> Zippy or similar on the other end (faster/worse), too.
>
> Greg
>
> _______________________________________________
> Zlib-devel mailing list
> Zlib-devel at madler.net
> http://mail.madler.net/mailman/listinfo/zlib-devel_madler.net
More information about the Zlib-devel
mailing list