-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Faster decompression. #793
base: develop
Are you sure you want to change the base?
Conversation
Dear Maxpaj, Would you mind explaining what in your view is bogus? Did you test the code performance? |
It might be a good idea to split your PR into multiple functional commits explaining each change in detail. This allows each change to be performance tested individually. |
I appreciate your constructive comments. The changes are intermingled, so it is difficult to split them into multiple commits in a clear-cut way. How about I amend a document to contrast each of the critical changes and explain the underlying reasons? |
I am waiting for the proposer's to-do list to be completed, and I will then test the commit for speed and inspect for correctness and portability. I will then consider whether I should merge it or some rewrite of it.I do not require that this be split into multiple commits. |
- added inflateBackWrap() for stand-alone validation of inflateBack(). Moreover, inflateBackWrap() exhibits identical functionality as in inflate(). - added comments for code revisions - added log in ChangeLog
I have created inflateBackWrap() to validate inflateBack(). Moreover, inflateBackWrap() exhibits identical functionality as inflate(). This allows for an apple-to-apple comparison of performance between inflate() and inflateBack() under different setups. @madler, could you take over and review the code? Feel free to make changes in your manner. |
Hi @madler, may I ask what the current status of this work. we'd like to enable Intel DEFLATE IAA/QAT in-kernel support for EROFS, but we'd also like to have a faster DEFLATE software decompression fallback support anyway. I'm not sure if zlib official codebase could address that (otherwise zlib-ng codebase has to be considered instead) since DEFLATE-family is currently a de-facto standard for various common use cases/formats, and better optimized (de)compression for those modern processors could benefit all of us. And I guess old 16-bit platforms are unimportant now since they could still be supported by old stable zlib versions. |
This is on my to-do list. |
I made the following changes to effectively boost the decompression throughput (~40% over Silesia Corpus)
Need to do:
Validate 32-bit CPU
Validate infback()
Add abundant comments in the final stage