-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
perf: Speedup cachekv iterator on large deletions & IBC v2 upgrade logic #10741
perf: Speedup cachekv iterator on large deletions & IBC v2 upgrade logic #10741
Conversation
On 1M deletes, an iterator creation took: BenchmarkIteratorOnParentWith1MDeletes-16 1 1112540940 ns/op
// The keys[1:] is to keep at least one entry in parent, due to a bug in the SDK iterator design. | ||
// Essentially the iterator will never be valid, in that it should never run. | ||
// However, this is incompatible with the for loop structure the SDK uses, hence | ||
// causes a panic. Thus we do keys[1:]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This bug is not related to this PR, I just noticed it in constructing the benchmark / working with the relevant logic.
This can be spot checked if folks want by just checking out the first commit in this PR, and removing the [1:]
.
This should probably moved to its own issue where we discuss the iterator structure, but its relatively low priority given all the other module / app writing improvements in the works 🙏
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome work, LGTM and thank you @ValarDragon for the change and for the keen eyes!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎉
…gic (backport #10741) (#10744) * perf: Speedup cachekv iterator on large deletions & IBC v2 upgrade logic (#10741) (cherry picked from commit 314e1d5) # Conflicts: # CHANGELOG.md # store/cachekv/store_bench_test.go * fix conflicts * add helpers Co-authored-by: Dev Ojha <[email protected]> Co-authored-by: marbar3778 <[email protected]>
…gic (backport #10741) (#10745) * perf: Speedup cachekv iterator on large deletions & IBC v2 upgrade logic (#10741) (cherry picked from commit 314e1d5) # Conflicts: # CHANGELOG.md # store/cachekv/store_bench_test.go * fix conflicts Co-authored-by: Dev Ojha <[email protected]> Co-authored-by: marbar3778 <[email protected]>
…gic (backport #10741) (#10746) * perf: Speedup cachekv iterator on large deletions & IBC v2 upgrade logic (#10741) (cherry picked from commit 314e1d5) # Conflicts: # CHANGELOG.md # store/cachekv/store_bench_test.go * fix conflicts Co-authored-by: Dev Ojha <[email protected]> Co-authored-by: marbar3778 <[email protected]>
…gic (backport cosmos#10741) (cosmos#10745) * perf: Speedup cachekv iterator on large deletions & IBC v2 upgrade logic (cosmos#10741) (cherry picked from commit 314e1d5) # Conflicts: # CHANGELOG.md # store/cachekv/store_bench_test.go * fix conflicts Co-authored-by: Dev Ojha <[email protected]> Co-authored-by: marbar3778 <[email protected]>
…gic (backport cosmos#10741) (cosmos#10745) * perf: Speedup cachekv iterator on large deletions & IBC v2 upgrade logic (cosmos#10741) (cherry picked from commit 314e1d5) # Conflicts: # CHANGELOG.md # store/cachekv/store_bench_test.go * fix conflicts Co-authored-by: Dev Ojha <[email protected]> Co-authored-by: marbar3778 <[email protected]>
…gic (backport cosmos#10741) (cosmos#10745) * perf: Speedup cachekv iterator on large deletions & IBC v2 upgrade logic (cosmos#10741) (cherry picked from commit 314e1d5) * fix conflicts Co-authored-by: Dev Ojha <[email protected]> Co-authored-by: marbar3778 <[email protected]>
…gic (backport cosmos#10741) (cosmos#10744) * perf: Speedup cachekv iterator on large deletions & IBC v2 upgrade logic (cosmos#10741) (cherry picked from commit 314e1d5) # Conflicts: # CHANGELOG.md # store/cachekv/store_bench_test.go * fix conflicts * add helpers Co-authored-by: Dev Ojha <[email protected]> Co-authored-by: marbar3778 <[email protected]>
…gic (backport cosmos#10741) (cosmos#10744) * perf: Speedup cachekv iterator on large deletions & IBC v2 upgrade logic (cosmos#10741) (cherry picked from commit 314e1d5) # Conflicts: # CHANGELOG.md # store/cachekv/store_bench_test.go * fix conflicts * add helpers Co-authored-by: Dev Ojha <[email protected]> Co-authored-by: marbar3778 <[email protected]>
Description
This PR provides extreme speedups to the iterator creation pattern used in upgrades from IBC v1 to v2. On Osmosis, executing an upgrade from a state export was taking us over 2 hours due to this bug. (We never let it finish) After this fix, it takes under 8 minutes. (There is then ~20-30 min time overhead for IAVL commit, but thats orthogonal)
Essentially the CacheKVStore previously would iterate over every deleted item in cache when constructing an iterator. In the upgrade logic, bank first migrates the entire store, rewriting everything. (And thus adding 100k + deletes, other upgrades added far more deletes as well. Guestimmated that Osmosis had around 500k deletes) Then in IBC's upgrade, you do at least two iterator constructions per IBC client, which on Osmosis there are ~2000. This adds up to the at least two hours we were experiencing.
This PR adds a benchmark to highlight the speed improvement, RAM improvement, and fixes this.
Thus this fix really does solve the problem
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.
I have...
!
to the type prefix if API or client breaking changeCHANGELOG.md
Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.
I have...
!
in the type prefix if API or client breaking change