perf(levm): new memory model #3564
Merged
Conversation
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
Lines of code reportTotal lines added: Detailed view |
|
No significant difference was registered for any benchmark run. Detailed ResultsBenchmark Results: BubbleSort
Benchmark Results: ERC20Approval
Benchmark Results: ERC20Mint
Benchmark Results: ERC20Transfer
Benchmark Results: Factorial
Benchmark Results: FactorialRecursive
Benchmark Results: Fibonacci
Benchmark Results: FibonacciRecursive
Benchmark Results: ManyHashes
Benchmark Results: MstoreBench
Benchmark Results: Push
|
Benchmark for 7bf6dbbClick to view benchmark
|
Benchmark for e945949Click to view benchmark
|
Benchmark Results: Factorial
Detailed ResultsBenchmark Results: BubbleSort
Benchmark Results: ERC20Approval
Benchmark Results: ERC20Mint
Benchmark Results: ERC20Transfer
Benchmark Results: Factorial
Benchmark Results: FactorialRecursive
Benchmark Results: Fibonacci
Benchmark Results: FibonacciRecursive
Benchmark Results: ManyHashes
Benchmark Results: MstoreBench
Benchmark Results: Push
|
Benchmark for fdfda3fClick to view benchmark
|
Benchmark Results: FactorialRecursive
Benchmark Results: MstoreBench
Detailed ResultsBenchmark Results: BubbleSort
Benchmark Results: ERC20Approval
Benchmark Results: ERC20Mint
Benchmark Results: ERC20Transfer
Benchmark Results: Factorial
Benchmark Results: FactorialRecursive
Benchmark Results: Fibonacci
Benchmark Results: FibonacciRecursive
Benchmark Results: ManyHashes
Benchmark Results: MstoreBench
Benchmark Results: Push
|
Benchmark for 1bf004dClick to view benchmark
|
Benchmark Block Execution Results Comparison Against Main
|
Benchmark Results: FactorialRecursive
Detailed ResultsBenchmark Results: BubbleSort
Benchmark Results: ERC20Approval
Benchmark Results: ERC20Mint
Benchmark Results: ERC20Transfer
Benchmark Results: Factorial
Benchmark Results: FactorialRecursive
Benchmark Results: Fibonacci
Benchmark Results: FibonacciRecursive
Benchmark Results: ManyHashes
Benchmark Results: MstoreBench
Benchmark Results: Push
|
Benchmark for 804e443Click to view benchmark
|
Benchmark for 5ff7ec8Click to view benchmark
|
Benchmark for 81c980aClick to view benchmark
|
Oppen
reviewed
Jul 16, 2025
Oppen
reviewed
Jul 16, 2025
Oppen
reviewed
Jul 16, 2025
Oppen
reviewed
Jul 16, 2025
Oppen
reviewed
Jul 16, 2025
JereSalo
reviewed
Jul 16, 2025
There was a problem hiding this comment.
I wonder why we changed some + for wrapping_add. In some places it doesn't seem to be necessary, is it?
Some of the usize::MAX sets that we do could be replaced by an error like VeryLargeNumber? Maybe in some places the behavior is the same but I'm not completely sure.
We have to be careful with "early errors" from ? which can for example, prevent incrementing the gas (which needs to be done even if there is an error). Thats why. |
We don't need to increment gas when there's an error. Errors like that consume all gas left so it doesn't matter |
Actually the trick about not throwing the error, is that calculate_memory_size which is used for gas costs, doesn't error if the size is 0. This is why we use those dummy values instead of throwing an error earlier, because while the offset may fail to parse, size is 0 so it is valid. And if size is not 0 it will error later with a checked overflow. |
You're right, I forgot about the cases in which size was zero. |
JereSalo
approved these changes
Jul 17, 2025
d-roak
pushed a commit
to 1sixtech/ethrex
that referenced
this pull request
Jul 17, 2025
**Motivation** Gas benchmarks show an 23% improvement on opcode based timings and 12% on end to end. 30% improvement in mgas for mstore (before unsafe) After adding unsafe we see a 30% improvement on top of the mstore improvements and overall general improvements on other opcodes.
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jul 17, 2025
**Motivation** Improves sstore perfomance Requires #3564 From 1100 to over 2200 <img width="1896" height="281" alt="image" src="https://github.com/user-attachments/assets/7f5697a3-048c-4554-91bb-22839bb91d95" /> The main change is going from Hashmaps to BTreeMaps. They are more efficient for the type of storages we use, for small datasets (1k~100k i would say) they overperform hashmaps due to avoiding entirely the hashing cost, which seemed to be the biggest factor. This changes comes with 2 other minor changes, like a more efficient u256 to big endian and a change to backup_storage_slot.
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.
Motivation
Gas benchmarks show an 23% improvement on opcode based timings and 12% on end to end.
30% improvement in mgas for mstore (before unsafe)
After adding unsafe we see a 30% improvement on top of the mstore improvements and overall general improvements on other opcodes.