-
Notifications
You must be signed in to change notification settings - Fork 51
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
Rewrite proof decoding code to not use a separate map #1462
Conversation
Some preliminary benchmarking show a 25% to 30% gain both when decoding and when accessing a proof content, and that's not accounting for the fact that we can optimize accessing the proof content further by storing the partial key on the side to avoid decoding trie nodes multiple times. |
Everything now seems to work fine. |
Here are the benchmarks compared to the main branch:
|
I'm very happy with the direction of this change, plus it seems to fix some corner case situations that the missing tests didn't detect before. While the code isn't perfect, I'm going to merge this so that I can start working on other changes that are blocked on this one. |
Before this PR, decoding a proof builds a
BTreeMap
that basically duplicates the trie structure.Looking things up in the proof then consists in traversing the
BTreeMap
. It seems to me, however, that we would be better off traversing the proof itself rather than aBTreeMap
.This is what this PR does. Decoding a proof now builds a "proof layout" that is now traversed when looking things up in the proof.
As a side effect, the keys and prefixes are no longer passed as slices by as iterators. This should also slightly improve performances, as there are various locations where we builds
Vec
s just to pass them as parameter.Since the objective of this PR is to improve performance, I might throw it away if it turns out to be slower than before (which is why I did #1460 beforehand).