optimize inflate decoding hot path#264
Conversation
|
Thank you for this PR! As this is a heavy change to the core decompression logic, I will need to test and review this very carefully before releasing and I will probably only do so in a minor bump (i.e. v0.9). From a first look, it seems like a good change, but I'm concerned about the impact on bundle size for the inflate-only bundle. If the performance boost is only a few percent, but the bundle size for Just for my reference - was this PR created partially or fully with the assistance of AI coding agents? It doesn't affect mergeability, I'm just curious if they work well for finding these kinds of optimizations. |
|
Thank you for taking time to review it. For context, my module https://github.com/mertushka/haxball.js#-technologies currently uses pako for compression and decompression. It is an API wrapper module for @basro’s game, so I was checking what kind of benefit we can get from fflate speed improvements compared to pako. The inflate optimization itself was found by me. I used AI only for the GitHub benchmark workflows, as you can probably understand why, since setting those up is a bit boring and time consuming. I also did some experiments with my fork after fixing inflate. Turns out the real-world benefit is not really big enough for us to switch from pako to fflate right now. However, I still wanted to make the PR because the optimization looked useful. |
Fixes #252
This PR improves inflateSync performance by optimizing the deflate decode hot path.
The bottleneck was in the symbol decoding path; avoiding repeated lookup/reversal work makes inflate consistently faster.
Benchmark results after the fix:
https://github.com/mertushka/fflate/actions/runs/25835319048
https://benchmarklab.azurewebsites.net/Benchmarks/Show/35759/0/deflate---pako-vs-fflate---realistic--fork