2011/5/2 Michael Hope <michael.h...@linaro.org>: > On Mon, May 2, 2011 at 11:13 AM, Jan Seiffert > <kaffeemons...@googlemail.com> wrote: >> 2011/5/2 Michael Hope <michael.h...@linaro.org>: >> Hi Michael, Linaro Devs >> >>> I see similar numbers. >> >> Great to hear ;) >> Means i'm not totally on the wrong track > > Note that I've sent the results to zlib-dev. The copy to linaro-dev > was forwarded on rather than cross-posting. >
Yep, it came over zlib-dev a little later. [snip] >> Oh, and if it's not clear, this is only the adler32 speedup, because >> only adler32 is run in a loop. > > Any idea on how much time in a zlib decompress is spent in adler32? > Heavily depends on the data. Or more correct the compression factor. adler32 is calculated over the uncompressed data. So if you have data that compresses well, it will be fast to decompress (mostly inflate_fast doing memsets), and adler32 becoming a greater part of the whole thing (assuming that compression is always slow). That at least was my use case. I get sparse bitfields compressed with deflate send over the network. Compressed they are 300 to 30000 byte (more to the lower numbers, because they are mostly sparsely populated). Uncompressed they are 128k. My adler32 part was >= 33% of whole zlib time. Last year in april Stefan Fuhrmann also proposed x86 vector code (http://mail.madler.net/pipermail/zlib-devel_madler.net/2010-April/001938.html), he said he was doing stuff with svn (so compressed text?), he saw a total adler32 time of ~15%, by making adler32 3 times as fast he could lower that to ~5% So no, this code will not magically make your compression/decompression n times faster, but every bit helps, and i mean if it comes for free... [snip] > -- Michael > Greetings Jan -- Murphy's Law of Combat Rule #3: "Never forget that your weapon was manufactured by the lowest bidder" _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
