Thanks, I will try this.
Maybe the faster AcceptBlock (which is actually a faster Activate), since it should speedup getslice as well, may make the trie sync issue much less common.
Thus, when the network is updated, it may go away by itself.
So people please test the krnlx patch to death, and also we need to set a much higher hard limit for block number or make it dynamic (without this we can't push the improvement to production).
A few words about my patch:
I. What is doing TrieView::Activate ?
We have two chains with blocks:
Code:
1,2,3,4,5,6,7,8,....,99,100,103,104
Code:
1,2,3,4,5,6,7,8,....,99,100,101,102,105
blocks get listed backwards (pindex->pprev) into two lists:
Code:
104,103,100,....3,2,1
Code:
105,102,101,....3,2,1
then same blocks removing from lists(starting from 1), we getting:Code:
104,103
Code:
105,102,101
when we have a lot of blocks in chain, there is involved a lot of slow c++ boost staff (linked lists, memory allocs,etc)II. What I've done?
1.allocated two arrays, and filled it with pointers to blocks.
2. Then scan them backwards until index reached SAFE_UNIQ or the blocks become different. So we get:
Code:
94,95,96,97,98,99,100,103,104
Code:
94,95,96,97,98,99,100,101,102,105
3. fill two linked lists with this blocks4. then the original code works with those linked lists, which are short.
III.
I have never seen a situation where these two chains differ from each other by more than one block, but I did not rule out such an opportunity (for example 3 or more blocks in a row are orphan). If you rely on the fact that they will always differ by one block, then the code can be greatly simplified.
IV. Possible problems
1. Size for arrays: must be a bit more(number?), than block height. How correctly determine actual blockheight from TrieView::Activate?
2. Check my code for errors: it is small, but errors can exist : wrong indexes, which can cause illegal memory access, or incorrect results.
