Signatures are checked ahead of time in separate threads, and sufficient number of threads are default allocated.
Whenever you see block processing at 100%, then the bottleneck is the single-core speed of your system (it's processing operations and updating state).
The results are in:
4921cb8c4abe093fa173ebfb9340a94ddf5ace7aPerformance report (total).) -124225649 mswhich is34.5 hours, avg. block processing time (fromPerformance report at block) is1.423 ms/blockentering live mode) -143988777 mswhich is40 hours, avg. block processing time (fromSyncing Blockchain) is1.649 ms/blockI'm curious how @gtg measurements will look in comparison.
Sync to replay ratio shoots up the most in areas of low blockchain activity, which is understandable, since small blocks are processed faster than they can be acquired from network, but in other areas sync is still 10-20% slower.
And the likely reason I remembered sync as faster than that is due to difference in computer speed - my home computer appears to be over 60% faster than the one I was running above experiments on, which would mean it should almost fit the sync inside 24 hours.
For now I have results for first 50M blocks:
6:32:4543.466s61.132sx1.406411:03:0084.337s395.575sx4.690414:31:33103.266s182.288sx1.7652I just counted last 100k block times (cpu / real) so it's not a great measurement. I can have better numbers once I complete those runs. But it seems that replay with validation can somehow make a better use of multiple threads than validation during resync.
It might be the state undo logic slowing down blockchain processing in a sequential manner (this computation is probably skipped for replay+validate). But I doubt there is a way to disable it to check that, short of modifying the code for the test.
Probably we should modify the code dealing with checkpoints to skip undo logic up to the checkpoint. This would allow us to confirm if it is the bottleneck, and it would also give us a speedup when checkpoints are set if it turns out to be the bottleneck.
It should be easy to test - just cut out two lines with
sessionindatabase::apply_block_extended(I'm actually assuming that out of order blocks won't reach that routine during sync, but if they do, it would be a source of slowdown).I'd be surprised if undo sessions were the problem. They are relatively slow and worthy of optimization, but in relation to simple transactions, mostly custom_jsons, so their performance is significant when there is many of them, like during block production, reapplication of pending or in extreme stress tests with
colony+queen. During sync we only have one session per block.Yes, your assumption is correct, blocks are strictly processed in order during sync, the P2P code ensures this. If it's easy to test, let me know what you find out: I guess work with @gandalf so that the test is performed on the same machine as previous measurements.