Improve forkchoice updateHead

[twoeths]

Describe the bug

This is from a prater node with no validator

0624_prater_forkchoice_updateHead.cpuprofile.zip

a normal state transition takes 227.6m, 212.2 ms is for updateHead

We need to find a way to improve computeDeltas in forkchoice implementation.

Expected behavior

Not sure what the expectation is but I think forkchoice is designed to be lightweight, taking 90% of time per normal state transition for forkchoice is too much.

[twoeths]

I think one of the cost is the slowness of BigInt calculation in computeDeltas. One idea is to track effectiveBalance as number instead of BigInt since MAX_EFFECTIVE_BALANCE=32000000000 which is still in the range of number.

We need to write benchmark test for any solutions we want to go.

[dapplion]

Related #2455

[g11tech]

@dapplion assign pls

[dapplion]

After implementing head caching fork-choice runs take 0.5% of CPU time in a not overloaded node (no subnets). Worth to look into it but not an high priority.

Also note that metrics reads match what Tuyen got in the profile.

[twoeths]

As noted in #2332, effectiveBalance is always multiple of EFFECTIVE_BALANCE_INCREMENT so ideally we want to track the weight as 32, 31, 30 instead of 32000000000, 31000000000, 30000000000

[dapplion]

Current metrics the fork-choice cost is very low 👍

[dapplion]

Fork-choice updateHead cost is about ~1% of total CPU time currently. I think it can still be improved, but it's low priority

[dapplion]

Below is a CPU profile of running updateHead() in a loop inside a benchmark

As shown in other profiles it's clear than the vast majority of time is spent on computeDeltas. The below percentages are likely wrong since for some reason the stack traces appear as the stack frame bounces from updateHead to updateHead/computeDeltas.

Reviewing computeDeltas, it's a pretty simple function:

• Loop over votes
• for each vote resolve what's voting to and add / substract its weight from those nodes

[twoeths]

closing via #5882