-
Notifications
You must be signed in to change notification settings - Fork 46
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
feat: add OnDiskStorage #246
base: main
Are you sure you want to change the base?
Conversation
a3df4b4
to
ec8ee89
Compare
c2a00cc
to
bdc0491
Compare
src/storage/on_disk.rs
Outdated
&self, | ||
address: &alloy_primitives::Address, | ||
) -> Result<Option<super::AccountBasic>, Self::Error> { | ||
let tx = self.inner.begin_ro_txn()?; |
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.
- Can we reuse the same read-only transaction (pool) instead of creating a new one on each read?
- Is it more performant to run concurrent transactions in separate threads for parallel mode?
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.
These are for performance optimization only, right? Can we postpone to another PR?
At least we should measure the current performance first. Otherwise, these optimizations look premature to me.
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.
We should benchmark and optimize right from this PR, so we don't have to check in and maintain unwanted code if it fails to demonstrate great speedup over in-memory storage. We can break the deduplicating bytecodes task down because each part is an instant improvement we want (to maintain).
These specific questions are important to improve our understanding. So that if on-disk storage shows promise but MDBX flops then hopefully we know why and seek a better alternative, like a more async I/O-friendly database and schema to avoid locks among worker threads.
So yeah, let's add a benchmark and optimize from there.
src/storage/on_disk.rs
Outdated
) -> Result<Option<super::AccountBasic>, Self::Error> { | ||
let tx = self.inner.begin_ro_txn()?; | ||
let Some(balance) = tx | ||
.open_table(Some("balance")) |
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.
Is it slow to call open_table
on every read?
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.
We need a benchmark to answer this question.
845f3cd
to
332539f
Compare
e3cb4ec
to
3c42de2
Compare
d5b6edf
to
a25555c
Compare
8c8c4dd
to
e721b87
Compare
e721b87
to
bd126ca
Compare
c3fabfc
to
176192b
Compare
638251a
to
ed9448b
Compare
ed9448b
to
9f26f38
Compare
Usage
Benchmark result