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

building computeKey cache on first fcu call #2748

Open
advaita-saha opened this issue Oct 17, 2024 · 4 comments
Open

building computeKey cache on first fcu call #2748

advaita-saha opened this issue Oct 17, 2024 · 4 comments
Labels

Comments

@advaita-saha
Copy link
Contributor

advaita-saha commented Oct 17, 2024

noValidation* {.
hidden
desc: "Disble per-chunk validation"
defaultValue: true
name: "debug-no-validation".}: bool

The default mode should be with validation, will also smooth out the UX from import to syncer. As with validation the triggering of the computeKey cache won't take place with the first fcu call which takes hours and results in the fcu call being timed out

Suggestion: defaultValue: false

@advaita-saha advaita-saha changed the title building of accounts on first fcu call building computeKey cache on first fcu call Oct 17, 2024
@arnetheduck
Copy link
Member

Changing the default here increases the total time it takes to import + compute cache - the way forward here is probably to check that a cache is available on normal (non-import) startup or something similar to that effect, so that it is computed before turning on networking.

@advaita-saha
Copy link
Contributor Author

Yes there is slow down, but personally as far as I ran imports for holesky and sepolia. The slowdown is not very significant. But yes the approach for checking on start does makes sense.

@arnetheduck
Copy link
Member

The slowdown is not very significant.

you can measure it to quantify this point, but that only makes sense to do so at mainnet scale, ie around block 20m where the database no longer fits in memory.

@jangko jangko added the EL label Oct 19, 2024
@arnetheduck
Copy link
Member

#2788 addresses this somewhat

The slowdown is not very significant.

a significant part of the slowdown is due to the separation of vertex and key data in the database - when the database is big, this leads to a lot of read/write amplification as each mpt node has to be read from two tables - it's worth remembering for future reference however - if we were to join the two tables, it might very well be the case that computing during import is decently fast.

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