Closed evanwashere closed 3 years ago
Looks good. I'll probably test this a bit further before merging though - I think this optimization can be applied elsewhere too.
By the way - I noticed you're using this in ImageScript and applied some optimizations with >> 3
over / 8
, ===
/!==
vs ==
/!=
, etc. From my prior empirical testing, bit shifting is actually slower than division + OR (I think due to the ToUint32 requirement), and the non-strict operators aren't any faster but lead to larger bundle size. However, if you have a POC for the perf uplift, I'm happy to implement those as well.
ToUint32 is slower than ToInt32 so i mostly avoid it when possible and use i32
yeah bit shifting doesn't improve anything in v8 as it's smart enough to already do this optimization, but my use is not limited to v8, so I'll keep it
for ==
vs ===
v8 jit saves the day again but like I said I expect my code to run on various engines which might not even have jit, so strict equality is guaranteed to be cheaper/faster
if jit can't guess types or if for any reason decides to not give fuck then !=
will result in more cycles than !==
btw cool project you got here
fflate is pretty heavily biased to V8 but it's true that other environments will have different/worse optimizations, so maybe those changes are valid. I had previously used bit shifts for bit to byte, but now I don't because it fails for >512MB files (obvious reasons). I think I'll investigate manually in other browser engines (mainly JSC and SpiderMonkey) where triple eq is better.
Thanks for the info (and effort).
this casts length into i32 while assuming chunk will never be larger than i32