adler32 optimization about pako HOT 6 CLOSED

5552 is limit for 32 bit int, calculated by someone clever :) . This constant exists in all implementations. I don't remember details.

Also, i can advice you to dig adler32 in native zlib sources, it has 2 unrollings. Those are stripped here as "not making sense for JS"

from pako.

5552 is limit for 32 bit int, calculated by someone clever :)

@puzrin 5552 actually comes from the same formula (you assume the worst case):

(* Run this in Mathematica *)
(* n is the maximum value for a term -- 255 for bytes *)
(* bits is the size of the containing value -- 31 for signed 32 bit ints, 32 for unsigned *)
G[n_, bits_] :=  Reduce[x*(x + 1)*n/2 + (x + 1)*(65521) < (2^bits - 1) && x > 0, x, Integers]
G[255, 32] (* x \[Element] Integers && 1 <= x <= 5552 *)

from pako.

May be. There should be no noticeable difference, when this value > 1000 (benchmarked). I just quickly taken safe value and switched to another task.

from pako.

On node, it appears the performance benefit comes from the structure of the loop:

Your loop involves two variables (n and pos), both moving in lockstep:

https://github.com/nodeca/pako/blob/master/lib/zlib/adler32.js#L19-L22

This can actually be done with one moving variable (calculate the intermediate goalpost and just increment the address):

https://github.com/SheetJS/js-adler32/blob/master/adler32.js#L27-L31

from pako.

May be, As i explainted in email, i have no special interest to participate in minor optimizations. If you wish - create a benchmark, that demonstrate that whole inflate/deflate can have noticeable benefits, and i'll be glad to accept pull request.

I'm not out of programming. Just have to concentrate on another tasks, like refactoring js-yaml, mincer and developping main nodeca project.

from pako.

Closed - timed out, not significant. When improvments, confirmed with pako benchmarcs available - just create a new ticket.

from pako.