Use fold/reduce to avoid locks in shrink accounts collection

[HaoranYi]

Problem

Motivated by #34011, we can use
fold/reduce to avoid locks in shrink accounts collection.

Summary of Changes

fold/reduce to avoid locks in shrink accounts collection.

Fixes #

[codecov]

Codecov Report

Merging #34042 (54e6720) into master (a25eae4) will increase coverage by 0.0%.
Report is 3 commits behind head on master.
The diff coverage is 96.5%.

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #34042   +/-   ##
=======================================
  Coverage    81.9%    81.9%           
=======================================
  Files         811      811           
  Lines      219569   219573    +4     
=======================================
+ Hits       179901   179920   +19     
+ Misses      39668    39653   -15     

[brooksprumo]

Love it. Are there perf numbers for before and after?

[HaoranYi]

Love it. Are there perf numbers for before and after?

No. do you have a good way to bench this change?

[brooksprumo]

Love it. Are there perf numbers for before and after?

No. do you have a good way to bench this change?

Looks like there's a Measure around the fold+reduce, index_read_elapsed. And it's put into the ShrinkStats. This is then reported as a datapoint with the name "shrink_stats", and the field is also "index_read_elapsed".

I think if you use the same snapshot and do not skip the initial shrink, then that may be a way to compare?

Another option is to spin up two nodes; one with this change and one without. Let them run for a bit, then swap. This should let you compare with and without this change.

[HaoranYi]

I tried ledger tool verify but it seems not hitting shrink during the run. I am going to spin up two nodes to compare instead.

[HaoranYi]

red: master
blue: this pr

it seems to be slightly better with this pr, but also shows lots of noise.

[brooksprumo]

it seems to be slightly better with this pr, but also shows lots of noise.

Nice. Now can you swap which node is running the pr vs master? That'll add another set of datapoints to compare.

We'll want to see (ideally) that when the node goes from PR to master, its perf drops. And the node that goes from master to PR, its perf increases.

[HaoranYi]

swapped.
red: this pr
blue: master
This time blue is still better. looks like dev7 is always better. So the performance improvement is not conclusive.

[brooksprumo]

Yeah, it's hard for me to draw conclusions. How do you recommend we proceed?

[HaoranYi]

Since there is no much improvement, let's close it.