-
-
Notifications
You must be signed in to change notification settings - Fork 318
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
fix: improve compute new state root when producing block #6195
Conversation
@@ -104,6 +104,12 @@ export class PrepareNextSlotScheduler { | |||
RegenCaller.precomputeEpoch | |||
); | |||
|
|||
// cache HashObjects for faster hashTreeRoot() later, especially for computeNewStateRoot() if we need to produce a block at slot 0 of epoch | |||
// see https://github.com/ChainSafe/lodestar/issues/6194 | |||
const hashTreeRootTimer = this.metrics?.stateHashTreeRootTime.startTimer({source: "prepare_next_slot"}); |
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.
What should be the naming convention we use for source?
e.g. here we use camelCase (function names)
onStateCloneMetrics(postState, metrics, "stateTransition"); |
and recently added (#6143) step metrics also use camelCase
const timer = metrics?.epochTransitionStepTime.startTimer({step: "afterProcessEpoch"}); |
I kinda like the function names and might be better for consistency, but maybe not always applicable (i.e. if there is no function call specific to the metric)
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.
What should be the naming convention we use for source?
agree to have some naming convention, we used snake case as suggested by @dapplion and that's my preference. Agree there are consistencies so need some agreement to work on
I don't want to use function names, just which whatever name that makes sense in the context because:
- some function names are so long so it's not nice to render in grafana, for example
verifyBlocksStateTransitionOnly
- one function could call a metric multiple times
so this one should be more dynamic to me, as long as a PR gets through review process we're fine I think
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 don't want to use function names, just which whatever name that makes sense in the context because:
Makes sense to not be to strict here then, also I guess those labels are mostly used to visualize and separate metric values in a panel. As long as it is visually readable and makes sense in the context of the metrics the naming convention (camelCase vs snake_case) should not matter that much.
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.
snake case just reads better in grafana :)
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## unstable #6195 +/- ##
=========================================
Coverage 90.35% 90.35%
=========================================
Files 78 78
Lines 8087 8087
Branches 490 490
=========================================
Hits 7307 7307
Misses 772 772
Partials 8 8 |
Performance Report✔️ no performance regression detected Full benchmark results
|
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.
lgtm
🎉 This PR is included in v1.13.0 🎉 |
Motivation
Improve "computeNewStateRoot" function
Description
computeNewStateRoot
was so slow because we didn't compute hash tree root to cache in "prepareNextSlot". The main fix for this is to do it in "prepareNextSlot"state.hashTreeRoot()
call in 3 places:verifyBlocksStateTransitionOnly()
,prepareNextSlot()
andcomputeNewStateRoot()
Closes #6194