allocation optimization for lz4frame compression #1158
Merged
+37
−8
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
as noted by @yixiutt in #1157, the temporary buffer managed by lz4frame compression context is being invalidated at end of compression, forcing it to be re-allocated at next compression job.
This shouldn't be necessary.
This behavior was introduced in #236, as a way to fix #232, but neither the issue is explained, nor why the patch fixes it.
This patch reverts to previous behavior,
where temporary buffer is reused between compression calls.
This results in a net reduction of allocation workload.
Additionally, the temporary buffer should only need
malloc(), notcalloc(), thus saving some potential 0-initialization cost.This diff implements both changes. It's expected to improve compression speed when repetitively compressing small data.
Performance impact on M1 laptop :
As expected, performance difference is only perceptible for small data, but it can matter a lot in this case.
Once this diff is merged, long fuzzer tests will be run to ensure that no sanitizer warning gets triggered.
Additionally :
LZ4F_decompress()LZ4F_compressUpdate()test tofullbench