Reduce Amount of Allocations - #376
Open
florianhartung wants to merge 10 commits into
Open
Conversation
florianhartung
force-pushed
the
dev/reduce-amount-allocations
branch
3 times, most recently
from
July 27, 2026 11:06
c2afbfd to
0e279fb
Compare
Codecov Report❌ Patch coverage is @@ Coverage Diff @@
## main #376 +/- ##
==========================================
- Coverage 88.15% 88.11% -0.05%
==========================================
Files 59 59
Lines 14769 14895 +126
Branches 14769 14895 +126
==========================================
+ Hits 13020 13125 +105
- Misses 1045 1061 +16
- Partials 704 709 +5
🚀 New features to boost your workflow:
|
florianhartung
force-pushed
the
dev/reduce-amount-allocations
branch
3 times, most recently
from
July 29, 2026 12:30
461e883 to
faea17c
Compare
cemonem
reviewed
Jul 29, 2026
| wasm.move_start_to(*span).unwrap_validated(); | ||
|
|
||
| let mut stack = Stack::new::<T>(Vec::new(), &FuncType::new_empty(), &[])?; | ||
| // If there is a stack to use, clear and reinitialize it. Otherwise create a new stack. |
Contributor
There was a problem hiding this comment.
in a future pr, we can remove this stack all together and have a flag if we're supposed to have more than 1 item in the stack (that we pretend to have) since all constexpr instructions are already values by themselves
Collaborator
Author
There was a problem hiding this comment.
AFAIK we discussed this topic already. For now, I'd like to keep the stack because it allows us to easily implement the Extended Const Expressions proposal (which is part of Wasm 3)
Collaborator
Author
Signed-off-by: Florian Hartung <florian.hartung@dlr.de>
Signed-off-by: Florian Hartung <florian.hartung@dlr.de>
Signed-off-by: Florian Hartung <florian.hartung@dlr.de>
Signed-off-by: Florian Hartung <florian.hartung@dlr.de>
Signed-off-by: Florian Hartung <florian.hartung@dlr.de>
Signed-off-by: Florian Hartung <florian.hartung@dlr.de>
Signed-off-by: Florian Hartung <florian.hartung@dlr.de>
Signed-off-by: Florian Hartung <florian.hartung@dlr.de>
Signed-off-by: Florian Hartung <florian.hartung@dlr.de>
…oding Signed-off-by: Florian Hartung <florian.hartung@dlr.de>
florianhartung
force-pushed
the
dev/reduce-amount-allocations
branch
from
July 31, 2026 12:57
faea17c to
a24225e
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Open Questions / TODOs
Benchmark Results
Coremark Results:
On main I get 311 and 312. On this branch I get 344 and 348.
I expect that the optimized br_table execution is responsible for this. Maybe it's in a hot loop somewhere. The coremark benchmark definitly contains ~10 br.table instructions
References
Checks
nix fmtnix flake check '.?submodules=1'cargo fmtcargo testcargo checkcargo buildcargo clippy --workspacecargo doc --document-private-items --workspace