-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge block_hashes.json
s into block_hashes.bincode
#441
Conversation
block_hashes.json
s into block_hashes.bincode
811acea
to
57c9bd2
Compare
57c9bd2
to
4ca1949
Compare
crates/pevm/tests/common/mod.rs
Outdated
handler( | ||
block, | ||
InMemoryStorage::new(accounts, Some(&bytecodes), block_hashes), | ||
InMemoryStorage::new(accounts, Some(&bytecodes), block_hashes.clone()), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use reference, just like &bytecodes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe the data amount is not much, but this is for the sake of consistency.
Also, .clone
is widely considered as anti-pattern when using reference (&
) is easy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just in case, InMemoryStorage
requires iterator with owned values, so its either block_hashes.iter().cloned()
or just block_hashes.clone()
.
pevm/crates/pevm/src/storage/in_memory.rs
Line 21 in 09bb59a
block_hashes: impl IntoIterator<Item = (u64, B256)>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This means InMemoryStorage
should be changed to accept a reference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The spirit is the same. bytecodes
and block_hashes
are readonly values. InMemoryStorage
only "views" them, not own them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe a reference is sufficient. Using Arc
will be an overkill. Anyway, it's not bad.
Arc
comes with a small performance cost. Therefore, please run a benchmark (using cargo bench
and crates/pevm/benches/report.py
) to make sure that the performance is not affectted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It shouldn't though. It is just a fancy pointer to (AtomicUsize, AtomicUsize, T)
, so, each time you dereference Arc
you just read pointer (but now it is with offset of 2 machine words) 🤷♂️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But my take here is that it would be easier to manage Arc
over wrangling (now 2) lifetimes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not a fan of premature Arc
s over &
but 2 Option<&>
s with 2 potentially different lifetimes look pretty unpleasant. So yeah, Arc
is justified here (not premature).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This https://github.com/risechain/pevm/pull/441/files#r1892852724 is a blocking issue. The rest looks good to me.
Here are benchmarks: Before (all logs in pastebin and under spoiler below):
Spoiler warning
After (pastebin)
Spoiler warning
Most of the blocks within statistical threshold. |
@kien-rise added reports under spoiler in the same comment. Take a look 🙏 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few nits but looks great overall!
I just realized storing the block hashes as JSON is fine as they're not that big, and being JSON makes it easy to manually cross-check with an explorer/RPC when things go wrong.
That said, bincode
everything to save Mother Earth is the future here. If we need debuggability we can extend the tests or CLI to auto cross-check the checked-in block hashes with RPC :).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
Closes #241
Depends on #440. But anyway, only last 2 commits are relevant to this pr