Skip to content

optimize inflate decoding hot path#264

Open
mertushka wants to merge 1 commit into
101arrowz:masterfrom
mertushka:inflate-performance-upstream
Open

optimize inflate decoding hot path#264
mertushka wants to merge 1 commit into
101arrowz:masterfrom
mertushka:inflate-performance-upstream

Conversation

@mertushka
Copy link
Copy Markdown

Fixes #252

This PR improves inflateSync performance by optimizing the deflate decode hot path.

  • Adds a precomputed lookup map for Huffman decode tables.
  • Uses the map in the inflate loop to reduce repeated decode work.
  • Keeps the existing inflate behavior/API unchanged.
  • Includes the helper in worker dependency lists so async inflate paths still work.

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

@101arrowz
Copy link
Copy Markdown
Owner

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 inflateSync only increases from 3kB to 4kB, this may not be worthwhile for this project.

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. fflate currently contains no AI-generated code and I have been hesitant to use such tools thus far. So I'm just curious if AI works well on this project or if you just happen to be a very talented developer :)

@mertushka
Copy link
Copy Markdown
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Performance advantage over pako might not be true for inflateSync?

2 participants