-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
perf(stages): Adds benchmark to TransactionLookupStage
#1130
Conversation
let last = cursor_txhash.last()?; | ||
let mut append = last.is_none(); | ||
if let (false, Some((last_txhash, _))) = (tx_list.is_empty(), last) { | ||
append = last_txhash < tx_list[0].0; |
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 are comparing it with the first in the list, should tx_list
be sorted at this pont?
self.query(|tx| { | ||
let last = tx.cursor_read::<T>()?.last()?; | ||
Ok(last.is_none()) | ||
}) | ||
} | ||
|
||
/// Return full table as Vec | ||
pub(crate) fn table<T: Table>(&self) -> Result<Vec<(T::Key, T::Value)>, DbError> | ||
pub fn table<T: Table>(&self) -> Result<Vec<(T::Key, T::Value)>, DbError> |
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.
let's clippy allow this
crates/stages/benches/criterion.rs
Outdated
let tx = prepare_blocks(NUM_BLOCKS).unwrap(); | ||
|
||
measure_txlookup_stage(&mut group, tx); | ||
} |
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 would add manual implementations of various access patterns in a loop, in addition to testing the stage itself. might be easier to compare specific parts if e.g. you have a bench that does X put
s vs sorted w/ cursor etc.
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.
For append
we know it is fastest if table is empty, question is what is better if we already have some values with random keys in the table and want to insert an additional batch?
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.
yeah i should add those scenarios, however I'll probably put those elsewhere since they're more db specific? this seems like it should be only for stage benchmarking? (eg. reading from different tables and aggregating into one; mem vs disk read -> write, etc)
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.
Added it on 100cea. There is a clear difference between presorted insert and unsorted insert.
cargo bench --package reth-db --bench hash_keys
However, it's not that "visible" in the stage itself. I think because we're allocating all the data into a list before sorting+inserting it. Whereas, in the current state, we're just passing the value into put
. But will need to run some more benches I guess
Pulled the parts about stage benchmarking here: #1171. Let's keep investigating the DB-specific patterns here. |
TransactionLookup bench on main:
And this PR:
Pretty significant improvement! Nice. What else do we need to review this?
^Is this still relevant? @joshieDo |
Just leaving here some results and thoughts for inserting into a table with keys as hashes. Notes:
BenchmarksThoughts
The table size being bigger for |
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.
smol nits
let mut tx_cursor = tx.cursor_write::<tables::Transactions>()?; | ||
let mut cursor_tx = tx.cursor_write::<tables::Transactions>()?; |
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 use <type>_cursor
everywhere else
// Sort before inserting the reverse lookup for hash -> tx_id. | ||
tx_list.sort_by(|txa, txb| txa.0.cmp(&txb.0)); | ||
|
||
let mut cursor_txhash = tx.cursor_write::<tables::TxHashNumber>()?; |
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.
let mut cursor_txhash = tx.cursor_write::<tables::TxHashNumber>()?; | |
let mut txhash_cursor = tx.cursor_write::<tables::TxHashNumber>()?; |
let mut append = last.is_none(); | ||
if let (false, Some((last_txhash, _))) = (tx_list.is_empty(), last) { | ||
append = last_txhash < tx_list[0].0; |
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.
let mut append = last.is_none(); | |
if let (false, Some((last_txhash, _))) = (tx_list.is_empty(), last) { | |
append = last_txhash < tx_list[0].0; | |
let append = tx_list.first().map(|(first_txhash)| last_txhash < first_txhash).unwrap_or_default(); |
Co-authored-by: Bjerg <onbjerg@users.noreply.github.com>
Opening for review. The issue of the |
Codecov Report
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more @@ Coverage Diff @@
## main #1130 +/- ##
==========================================
+ Coverage 75.29% 75.56% +0.26%
==========================================
Files 335 339 +4
Lines 36432 37707 +1275
==========================================
+ Hits 27433 28492 +1059
- Misses 8999 9215 +216
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
Tries to tackle #1092
Added one benchmark, but to be honest the difference I'm seeing seems too small ( 2 - 4 %). I was expecting a bigger difference (for 20k blocks) and I'm not sure if it can't be explained by my machine instability.
One way to test the stage before (
tx.put
) and after (pre-sort +crsr.append
):To test insertion of tables with hash keys :
Note: sorting is benchmarked on
insert_sorted
andput_sorted
.