[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