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

Optimize get candidate pools #469

Closed
wants to merge 1 commit into from

Conversation

cuongquangnam
Copy link

  • What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)

  • What is the current behavior? (You can also link to an open issue here)

  • What is the new behavior (if this is a feature change)?

  • Other information:

@cuongquangnam cuongquangnam requested a review from a team as a code owner January 9, 2024 06:58
Copy link
Contributor

@cgkol cgkol left a comment

Choose a reason for hiding this comment

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

why not! probably small differences but this will work

@@ -445,12 +445,12 @@ export async function getV3CandidatePools({
? subgraphPool.token1.id
: subgraphPool.token0.id;
})
.filter((secondHopId: string) => !tokensToAvoidOnSecondHops?.includes(secondHopId.toLowerCase()))
Copy link
Member

Choose a reason for hiding this comment

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

In theory, this filter logic should make flatMap instantiate less subgraphPool objects at runtime, and thus more performant. In practice, I think this change actually might bring perf overhead, due to the pools characteristics as well as lodash library.

So to give some context, back then, we noticed that lodash instantiates objects per function like filter and flatMap based on the perf analysis. Because of that, we initial tried to refactor both V2 and V3 subgraph pool selections without lodash #331. For some reason, we saw perf improvement in V2 pool selection, but perf regression in V3 pool selection, hence we reverted back V3 pool selection #340.

Next in V2 pool selection, we optimize the second hops if we have enough candidate pools for routes #371, as well as tracked the loop iterations in metrics #351. It turns out even with all those optimizations, V2 candidate pools were almost all iterated per quote request using our internal AWS metrics:

Screenshot 2024-01-10 at 2 47 11 PM

Thus we made the conclusion, that majority of the V2 pools do not have enough liquidities (we use TVL as approximate to TVL in SOR code), so no matter how we optimize to avoid second hops, at runtime, V2 candidate pools will be almost all iterated. Later on when I checked on https://v2.info.uniswap.org/pairs, the liquidities ranking does seem to show most V2 pools don't have high enough liquidities.

For V3, we don't have a metric to track how many tokens avoided the second hops, but from https://info.uniswap.org/home#/pools, I can that majority of the TVLs are concentrated in the top pools as well. This leaves me to think that the after .filter, majority of the V3 pools will still be there at runtime, and new pools objects will get instantiated. Then after flatMap new pools objects will get instantiated once more.

@jsy1218
Copy link
Member

jsy1218 commented Feb 9, 2024

We should close the PR given my explanation above.

@jsy1218 jsy1218 closed this Feb 9, 2024
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