Speedup TWAP pruning logic #7415
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
added
V:state/compatible/backport
ValarDragon
requested review from
nicolaslara,
p0mvn and
AlpinYukseloglu
as code owners
mattverse
approved these changes
Feb 6, 2024
| } | ||
| _, hasSeenPoolRecord := seenPoolAssetTriplets[poolKey] | ||
| if !hasSeenPoolRecord { | ||
| seenPoolAssetTriplets[poolKey] = struct{}{} | ||
| continue | ||
| } | ||
|
|
||
| k.DeleteHistoricalRecord(ctx, twapToRemove) |
There was a problem hiding this comment.
This method now seems unused, can we delete the method as well?
There was a problem hiding this comment.
Hrmm, seems like a useful helper / reference implementation tho
nicolaslara
reviewed
Feb 6, 2024
|
|
||
| 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) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
actually, ignore that. It would require a migration of existing keys.
There was a problem hiding this comment.
I think your right, alas wasn't thought about before. would take a migration now
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>
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
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 %)
IAVL v1 no fast nodes relevant pprof (ignore %)
The database I/O savings would have to come from elsewhere and be state incompatible