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

feat: syncer: optimize syncFork for one-epoch forks #11533

Merged
merged 1 commit into from
Dec 18, 2023

Conversation

arajasek
Copy link
Contributor

Related Issues

Towards #11530 (comment)

Logging and analysis have shown that nearly 100% of calls to syncFork are for a very specific case: when incoming.Parents() ⊂ known. Currently, we fetch 900 tipsets in this case. We actually need to fetch ZERO.

Proposed Changes

Check if there are any common blocks between known and incoming.Parents(). If there are, we simply need to return [incoming.Parents, incoming]. We know we already have incoming, so we just need incoming.Parents. We now check our local store to fetch incoming.Parents (which according to experiments we almost always do), and if we don't we fallback onto the network requesting the ONE tipset.

Additional Info

Checklist

Before you mark the PR ready for review, please make sure that:

  • Commits have a clear commit message.
  • PR title is in the form of of <PR type>: <area>: <change being made>
    • example: fix: mempool: Introduce a cache for valid signatures
    • PR type: fix, feat, build, chore, ci, docs, perf, refactor, revert, style, test
    • area, e.g. api, chain, state, market, mempool, multisig, networking, paych, proving, sealing, wallet, deps
  • If the PR affects users (e.g., new feature, bug fix, system requirements change), update the CHANGELOG.md and add details to the UNRELEASED section.
  • New features have usage guidelines and / or documentation updates in
  • Tests exist for new functionality or change in behavior
  • CI is green

@arajasek arajasek requested a review from a team as a code owner December 15, 2023 19:11
}

if commonParent {
// known contains at least one of incoming's Parents => the common ancestor is known's Parents (incoming's Grandparents)
Copy link
Contributor

Choose a reason for hiding this comment

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

Pretty sure this is a typo, as I parse it we only have the guarantee about common grandparents

2023-12-15-223158_1222x936_scrot

Suggested change
// known contains at least one of incoming's Parents => the common ancestor is known's Parents (incoming's Grandparents)
// known contains at least one of incoming's Parents => the common ancestor is known's Grandparents (also incoming's Grandparents)

Copy link
Contributor

Choose a reason for hiding this comment

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

(the logic does appear to be correct tho)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@magik6k No, I don't think this is right? The logic in 891-895 is checking whether incoming.Parents() has any blocks in common with known (so known = {A,B,C,D} in your diagram).

@arajasek arajasek merged commit 324748d into master Dec 18, 2023
89 checks passed
@arajasek arajasek deleted the asr/speedup-fork-sync branch December 18, 2023 20:09
@arajasek
Copy link
Contributor Author

Merging cuz the only outstanding discussion is about a comment, but happy to revisit.

rjan90 pushed a commit that referenced this pull request Jan 4, 2024
feat: syncer: optimize syncFork for one-epoch forks
rjan90 pushed a commit that referenced this pull request Jan 4, 2024
feat: syncer: optimize syncFork for one-epoch forks
@rjan90 rjan90 mentioned this pull request Jan 4, 2024
8 tasks
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