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

add NewPoolSimulatorV2 for uniswapv3 #306

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Conversation

it4rb
Copy link
Member

@it4rb it4rb commented Jan 12, 2024

Benchmark:
Before:
BenchmarkNewPoolSimulator-8 2350 511776 ns/op 242664 B/op 3778 allocs/op

After:
If we don't reuse PoolSimulator instance
BenchmarkNewPoolSimulatorV2-8 8212 146271 ns/op 157368 B/op 2673 allocs/op

Best case: if we keep reusing the same PoolSimulator (don't need to alloc new tick list array)
BenchmarkNewPoolSimulatorV2ReuseBestcase-8 12393 95657 ns/op 87663 B/op 88 allocs/op

Why did we need it?

Related Issue

Release Note

How Has This Been Tested?

Screenshots (if appropriate):

@it4rb it4rb requested review from 0xh9n and piavgh as code owners January 12, 2024 09:45
Copy link
Member

@cyberliem cyberliem left a comment

Choose a reason for hiding this comment

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

There are questions

Comment on lines +142 to +143
p := &PoolSimulatorV2{}
err := InitPoolSimulatorV2(entityPool, p, chainID)
Copy link
Member

Choose a reason for hiding this comment

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

looks weird, since we are not pre-loc p. Why do we have to write this type of pattern.

Copy link
Member Author

Choose a reason for hiding this comment

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

um this is for caller (for example combine-path lib) that want to simply create a simulator without worrying about pre-allocating simulator instance
(router-service will try to call InitPoolSimulatorV2 directly on the re-used instance)

// TickGob should be fully compatible with v3Entities.Tick (GobBigInt is just a wrapper around bigInt)
// this should always be checked with a unit test
// also, uninitialized tick should be ignored at pool-tracker/tick-based-worker already, so no need to check here
v3Ticks := *(*v3TickList)(unsafe.Pointer(&p.extra.Ticks))
Copy link
Member

Choose a reason for hiding this comment

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

will this assertion panic if the p.extra.Ticks is empty?

Copy link
Member Author

Choose a reason for hiding this comment

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

've added a testcase for empty list

@@ -59,6 +61,12 @@ type Tick struct {
LiquidityNet *big.Int `json:"liquidityNet"`
}

type TickGob struct {
Index int `json:"index"`
Copy link
Member

Choose a reason for hiding this comment

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

maybe we don't need to use json struct tag when using gob anymore?

Copy link
Member Author

Choose a reason for hiding this comment

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

um in this PR we only use Gob for 2 bigInt (liq gross and liq net), not the whole struct, so we'll still need these tags

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants