Skip to content
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

Speedup TWAP pruning logic #7415

Merged
merged 1 commit into from
Feb 6, 2024
Merged

Speedup TWAP pruning logic #7415

merged 1 commit into from
Feb 6, 2024

Conversation

ValarDragon
Copy link
Member

@ValarDragon ValarDragon commented Feb 5, 2024

Previously we were unmarshalling the value of all records we prune, and paying lots of time in re-formatting keys.

Instead we can gather all the data we need from the key we iterate over (and save us expensive unmarshals - .3s to .5s depending on GC). We also skip one key formatting, since thats the representation we are already iterating over (.12s to .21s depending on GC). We skip time formatting in the second key format (30ms AKA .03s) We could save more in the second key formatting w/ more code complexity.

I'd estimate we're adding .05s of overhead, which we should measure.

The net change of this should be between .42s to .72s off of epoch, and be state compatible.

IAVL v0 relevant pprof (ignore %)
image

IAVL v1 no fast nodes relevant pprof (ignore %)
image

The database I/O savings would have to come from elsewhere and be state incompatible

Previously we were unmarshalling the value of all records we prune,
and paying lots of time in re-formatting keys.

Instead we can gather all the data we need from the key we iterate over
(and save us expensive unmarshals - .3s to .5s depending on GC).
We also skip one key formatting, since thats the representation we
are already iterating over (.12s to .21s depending on GC).
We skip time formatting in the second key format (30ms AKA .03s)
We could save more in the second key formatting w/ more code complexity.

I'd estimate we're adding .05s of overhead, which we should measure.

The net change of this should be between .42s to .72s off of epoch,
and be state compatible.
@ValarDragon ValarDragon added V:state/compatible/backport State machine compatible PR, should be backported A:no-changelog A:backport/v22.x backport patches to v22.x branch labels Feb 5, 2024
@github-actions github-actions bot added the C:x/twap Changes to the twap module label Feb 5, 2024
Copy link
Member

@mattverse mattverse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! LGTM 🚀

}
_, hasSeenPoolRecord := seenPoolAssetTriplets[poolKey]
if !hasSeenPoolRecord {
seenPoolAssetTriplets[poolKey] = struct{}{}
continue
}

k.DeleteHistoricalRecord(ctx, twapToRemove)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method now seems unused, can we delete the method as well?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hrmm, seems like a useful helper / reference implementation tho


func FormatHistoricalPoolIndexTWAPKeyFromStrTime(poolId uint64, denom1, denom2 string, accumulatorWriteTimeString string) []byte {
var buffer bytes.Buffer
fmt.Fprintf(&buffer, "%s%d%s%s%s%s%s%s", HistoricalTWAPPoolIndexPrefix, poolId, KeySeparator, denom1, KeySeparator, denom2, KeySeparator, accumulatorWriteTimeString)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not relevant for this PR, but we may want to have a generic osmoutils.BuildKey(elements ...interface{}) that does this to avoid potential future key issues

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also, should this end un a KeySeparator? Right now we're not appending anything, but if someone adds a traling key part in the future it may become an issue

Suggested change
fmt.Fprintf(&buffer, "%s%d%s%s%s%s%s%s", HistoricalTWAPPoolIndexPrefix, poolId, KeySeparator, denom1, KeySeparator, denom2, KeySeparator, accumulatorWriteTimeString)
fmt.Fprintf(&buffer, "%s%d%s%s%s%s%s%s%s", HistoricalTWAPPoolIndexPrefix, poolId, KeySeparator, denom1, KeySeparator, denom2, KeySeparator, accumulatorWriteTimeString, KeySeparator)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually, ignore that. It would require a migration of existing keys.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think your right, alas wasn't thought about before. would take a migration now

@ValarDragon ValarDragon merged commit c5313af into main Feb 6, 2024
1 check passed
@ValarDragon ValarDragon deleted the dev/speedup_twap_prune branch February 6, 2024 16:39
mergify bot pushed a commit that referenced this pull request Feb 6, 2024
Previously we were unmarshalling the value of all records we prune,
and paying lots of time in re-formatting keys.

Instead we can gather all the data we need from the key we iterate over
(and save us expensive unmarshals - .3s to .5s depending on GC).
We also skip one key formatting, since thats the representation we
are already iterating over (.12s to .21s depending on GC).
We skip time formatting in the second key format (30ms AKA .03s)
We could save more in the second key formatting w/ more code complexity.

I'd estimate we're adding .05s of overhead, which we should measure.

The net change of this should be between .42s to .72s off of epoch,
and be state compatible.

(cherry picked from commit c5313af)
ValarDragon added a commit that referenced this pull request Feb 6, 2024
Previously we were unmarshalling the value of all records we prune,
and paying lots of time in re-formatting keys.

Instead we can gather all the data we need from the key we iterate over
(and save us expensive unmarshals - .3s to .5s depending on GC).
We also skip one key formatting, since thats the representation we
are already iterating over (.12s to .21s depending on GC).
We skip time formatting in the second key format (30ms AKA .03s)
We could save more in the second key formatting w/ more code complexity.

I'd estimate we're adding .05s of overhead, which we should measure.

The net change of this should be between .42s to .72s off of epoch,
and be state compatible.

(cherry picked from commit c5313af)

Co-authored-by: Dev Ojha <ValarDragon@users.noreply.github.com>
@github-actions github-actions bot mentioned this pull request Mar 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A:backport/v22.x backport patches to v22.x branch A:no-changelog C:x/twap Changes to the twap module V:state/compatible/backport State machine compatible PR, should be backported
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants