Speed up "Synchronizing DAO" by ~30% #5484
Conversation
Measure the entire parseBlock() duration, not just the substep of parsing transactions.
Improve isBlockHashKnown() by about 100ms per call by caching the hashes of the known blocks.
Method is duplicate of isBlockHashKnown().
Improve block lookup by height by introducing an index, instead of iterating through all blocks and comparing the height.
|
As by definition this needs an ACK by @ManfredKarrer to get merged. |
cd2357
changed the title
There was a problem hiding this comment.
@cd2357 Thanks for working on that.
There is missing the chache update when a new block is added in onNewBlockWithEmptyTxs.
Maybe its better to create explicit methods for daoState.getBlocks().addAll and daoState.getBlocks().add in DaoStateService.
|
@chimp1984 Thanks for doing a review as well! But still we'll need in the end the ACK by @ManfredKarrer as well. |
Just to be clear, it is a NACK at current state. Cache does not get updated at new blocks. |
Update the two new indices on every known write to the list, namely addBlock() and addBlocks(). Restrict ability to modify the blocks list outside of these methods by overwriting the getBlocks() getter such that it returns an unmodifiable list.
|
Done, thanks for the speedy review.
Good point. I restricted the adding of blocks to two new methods, |
Rename blocksByHash because it is not actually indexing blocks by hashes, instead it's a cache of known hashes.
|
So only the ACK by @ManfredKarrer is finally missing 😄 👍 |
BlockParser.parseBlock()normally takes about 300ms per block.One part of it is checking if the new block hash is known, which was done by string-comparing it to the hashes of all known blocks. In my case, this was about 110 000 string-comparisons per
BlockParser.parseBlock()call.This commit adds a block hash cache in the
DaoStateand replaces the hash string-comparisons by oneHashSetlookup.With this change,
BlockParser.parseBlock()takes around 200ms on my setup.