Optimise TrieLogPruner.preload #7350
Closed
Conversation
This file contains 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
|
Wall clock profiling of
|
|
The parallelization didn't work very well. For example , the main thread didn't execute any of the tasks, it was just waiting for the other threads from ForkjoinPool.commonPool, which is not the expected behaviour. The main thread with (numCPU - 1) other threads from ForkjoinPool.commonPool should do the work in a proportional way. |
Signed-off-by: Simon Dudley <[email protected]> Signed-off-by: Simon Dudley <[email protected]>
…ming keys Signed-off-by: Simon Dudley <[email protected]> Signed-off-by: Simon Dudley <[email protected]>
siladu
force-pushed
the
trie-log-preload-optimisation
branch
from
8eaf3f9
to
d165bda
Compare
|
Superceded by #7365 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
These optimisations only seem to save <= 17% of the time.
Control node took ~6mins.
Test node took between 5 mins and 5 mins 30 seconds on a couple of runs.
The problem with #7337 is that for the duration of the async load, block import time appears to be affected. This could lead to impaired attestation performance and a missed proposal (although admittedly better than the alternative of downtime).
Ultimately need another PR that used a reasonable timeout for this load+prune operation, maybe 30 seconds.