Merged
Conversation
github-actions
bot
added
levm
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
JereSalo
reviewed
Jul 16, 2025
Contributor
JereSalo
left a comment
JereSalo
left a comment
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.
Contributor
Author
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. |
Contributor
We don't need to increment gas when there's an error. Errors like that consume all gas left so it doesn't matter |
Contributor
Author
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. |
Contributor
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.
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jul 18, 2025
**Motivation** Improves from 200 mgas to 790, this bench was made with this pr along memory, sstore and opcodes ones. A 295% increase in perf. Requires the pr #3564 **Description**
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jul 22, 2025
**Motivation** <!-- Why does this pull request exist? What are its goals? --> **Description** <!-- A clear and concise general description of the changes this PR introduces --> We didn't realize that #3564 introduced a bug when storing data of length zero. This aims to fix it. I also delete a resize check that's completely unnecessary Tested the fix and it works. I now am able to execute the blocks mentioned in the issue of this PR without any problems at all. <!-- Link to issues: Resolves #111, Resolves #222 --> Closes #3775
MegaRedHand
pushed a commit
that referenced
this pull request
Jul 23, 2025
**Motivation** <!-- Why does this pull request exist? What are its goals? --> **Description** <!-- A clear and concise general description of the changes this PR introduces --> We didn't realize that #3564 introduced a bug when storing data of length zero. This aims to fix it. I also delete a resize check that's completely unnecessary Tested the fix and it works. I now am able to execute the blocks mentioned in the issue of this PR without any problems at all. <!-- Link to issues: Resolves #111, Resolves #222 --> Closes #3775
pedrobergamini
pushed a commit
to pedrobergamini/ethrex
that referenced
this pull request
Aug 24, 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.
pedrobergamini
pushed a commit
to pedrobergamini/ethrex
that referenced
this pull request
Aug 24, 2025
**Motivation** Improves sstore perfomance Requires lambdaclass#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.
pedrobergamini
pushed a commit
to pedrobergamini/ethrex
that referenced
this pull request
Aug 24, 2025
**Motivation** Improves from 200 mgas to 790, this bench was made with this pr along memory, sstore and opcodes ones. A 295% increase in perf. Requires the pr lambdaclass#3564 **Description**
pedrobergamini
pushed a commit
to pedrobergamini/ethrex
that referenced
this pull request
Aug 24, 2025
**Motivation** <!-- Why does this pull request exist? What are its goals? --> **Description** <!-- A clear and concise general description of the changes this PR introduces --> We didn't realize that lambdaclass#3564 introduced a bug when storing data of length zero. This aims to fix it. I also delete a resize check that's completely unnecessary Tested the fix and it works. I now am able to execute the blocks mentioned in the issue of this PR without any problems at all. <!-- Link to issues: Resolves lambdaclass#111, Resolves lambdaclass#222 --> Closes lambdaclass#3775
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
4 participants
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.