-
Notifications
You must be signed in to change notification settings - Fork 14
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
Make Trie Size MerkleDB compatible #451
Comments
Initial results for insertion and reading without extension nodesNote: This isn't supposed to be a perfect benchmark, this is just supposed to be a leading indicator of whether or not it's worth continuing to pursue MerkleDB compatibility by structure or request that MerkleDB add extension nodes. Branch Nodes with Paths (no Extension Nodes)1000 individual inserts without verification (no reads)
average time: 4.822s 2 individual inserts in batches of 100,000 without verification (no reads)
average time: 4.043s 1000 individual inserts with 100% verification
average time: 5.516s 2 individual inserts in batches of 100,000 with 100% verification
average time: 5.451s Branch Nodes without Paths (Extension Nodes)1000 individual inserts without verification (no reads)
average time: 4.973s 2 individual inserts in batches of 100,000 without verification (no reads)
average time: 4.238s 1000 individual inserts with 100% verification
average time: 5.263s 2 individual inserts in batches of 100,000 with 100% verification
average time: 5.473s SummaryResultsCopied from above Branch with path on top 1000 individual inserts without verification (no reads)average time: 4.822s 2 individual inserts in batches of 100,000 without verification (no reads)average time: 4.043s 1000 individual inserts with 100% verificationaverage time: 5.516s 2 individual inserts in batches of 100,000 with 100% verificationaverage time: 5.451s With this particular seed, only individual inserts with 100% verification were slower for the case of branch-nodes with paths. In my opinion, in stands to reason that it continues to be worth pursuing the removal of extension nodes in their entirety. Removing the extension nodes simplifies the code, allows for full MerkleDB hash compatibility, and does not appear to introduce any performance regressions at this time. |
Solved with new design |
This is a two-step process
Branch nodes will contain the compression and thus Extension nodes will only exist as dead-code
Landed in Add path to Branch-Nodes (don't use Extension-Nodes) #344
This part should be trivial
PlainCodec
Note:
We need to test the effects of adding a path to the branch-nodes on performance
The text was updated successfully, but these errors were encountered: