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.
Problem:
Working on using Chicory with real-world Wasm payloads, I noticed a huge pressure on the
memory_grow
op code.Basically, some C module, will keep growing the memory in very very small chunks, and, currently, this operation is really expensive as it needs a full copy to a new
ByteBuffer
.Proposal:
While it's definitely possible to tweak the WASM module memory allocator and swap in something more optimized, it's much better for us to decouple the guest module consumption.
In this way, we can decide to plug in more advanced and sophisticated heuristics based on the usage.
Implementation:
The implementation puts in places the necessary pieces, the "Default" allocator is not greatly smarter than the previous, but it already improves performance in the use case I was looking at.
It should be a bit better overall, but it definitely has margin for improvement.
Notes:
I provided an implementation to preserve the current behavior when necessary, but this is a behavioral change and we should roll it (if approved) with a minor version bump (i.e.
1.1.X
).@electrum : I'd be extremely interested if you take a little time to try out those changes with Python 🙏