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.
Hi,
I have been working a bit on perf, and following discussions with @AurelienFT, I think it's better to split it into separate prs
This one does not change any of the public api and I think should be easy and uncontroversial to merge
in total, this gives about a 20% improvement on the insert 40k random keys into a contract.
The benches use HashMap db and they are handcrafted, they may not accurately translate to these numbers in the real world - I am simply just following what the vtune profiler tells me is bad
For the other prs: the main one I really want adds a bonsai trie many_insert, which does GETs and tree traversal in parallel but I've had some complications as Rocksdb transaction object isnt Sync, which means I can't just reuse the existing transactional state merge api without having to change it quite a bit
I think I have come up with a better way though, so I'll drop the PR asap and we'll see then if it's nice enough
The other one is about switching all keys to smallvec storage, it kind of changes the api a bit at some places