-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
R4R: Refactor Iterator Gas Consumption #2357
Conversation
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.
Is the Gas Iterator based off of the CacheKVStore?
Under the current implementation, iterator creation should be charging n log n
in size due to the sorting, and we don't really need to charge for next calls. If we go with the optimizations mentioned in #2286 then we'd have to make inserting into there cost log_2 n
, and ignore what I said about n log n
. Not sure how to do this without having cache kv store communicate more than whats in the store interface though.
If this is directly going to IAVL, this implementation makes sense.
Yes, well it can be -- BaseApp calls
Due to
Why? Ultimately, a DB read could be performed, no? |
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.
Thanks @alexanderbez, see comments.
store/gaskvstore.go
Outdated
} | ||
return newGasIterator(gi.gasMeter, gi.gasConfig, parent) | ||
|
||
gs.gasMeter.ConsumeGas(gs.gasConfig.IterInitCostFlat, sdk.GasIterInitCostFlatDesc) |
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.
I think when we call parent.Iterator
(or parent.ReverseIterator
) it already seeks to the first value, so we should charge key and value cost as with .Next()
. I don't know if we need a flat cost but having that too is definitely safe.
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.
Will amend to have initialization incur a cost of akin to .Next()
-- this will actually result in the removal of the IterInitCostFlat
.
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.
also you have to double-check Valid()
here and maybe below too before calling .Value()
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.
otherwise it will panic!
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.
Indeed.
No, the cost model is based off an underlying IAVL tree. I think we can just ignore the cache layer for now, although in the future it would be nice if we could charge less for cacheable reads or repeated writes to the same location. |
Iirc, when doing an iterator on a cache kv store, the dirty items are all in memory and sorted. So reading from IAVL isn't happening on
This feels very odd that we're charging for computation thats not happening but your right, thats #postlaunch able. I'll take another look at the PR, what Bez wrote from what I remember is correct with that mindset. |
|
Codecov Report
@@ Coverage Diff @@
## develop #2357 +/- ##
=========================================
Coverage ? 65%
=========================================
Files ? 135
Lines ? 8423
Branches ? 0
=========================================
Hits ? 5475
Misses ? 2587
Partials ? 361 |
Addressed your comments @cwgoes 👍 |
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
LGTM but not merging yet so @ValarDragon has another chance to review.
@ValarDragon bump. |
// No gas costs for deletion | ||
gi.parent.Delete(key) | ||
gs.parent.Delete(key) |
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.
I know you didn't change this, but why is deleting 0 cost? Shouldn't it be at least as complex as Has
?
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 is a good observation. We're freeing up space, but I agree it should charge the same price as Has
. Thoughts @cwgoes ?
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.
We don't charge because space is freed - but actually this might be a DoS vector though, good catch. Let's charge the same as Has
.
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 - thanks @alexanderbez
gasIterator#Key
andgasIterator#Value
.gasKVStore#iterator
) andgasIterator#Next
.Next()
include the dynamic cost of the value's length.Next()
to be the sum of the old flat costs ofKey()
(5) andValue()
(10).I did not choose to implement
UnsafeGetParent
as I think that should be a for a separate PR if we so decide to want it.closes: #2017
Targeted PR against correct branch (see CONTRIBUTING.md)
Linked to github-issue with discussion and accepted design OR link to spec that describes this work.
Wrote tests
Updated relevant documentation (
docs/
)Added entries in
PENDING.md
with issue #rereviewed
Files changed
in the github PR explorerFor Admin Use: