perf: improve extend_sorted_vec & batch write hashed_state

[duyquang6]

As discussed #19739 (comment)
Batch write of hashed_state is safe, so I created this PR to cherry-pick old reverted commit

Changes

• improve extend_sorted_vec use merge (avoid sort at the end) and batch write hashed_state

before

erc20 transfers spam: ~100ms

native transfers spam: ~50ms

after

erc20 transfers spam: ~80ms

native transfers spam: ~30ms

[mattsse]

pedantic doc nit

[mediocregopher]

The previous implementation was specifically designed to avoid having to do a big collect like this; the resulting memory allocation from this collect dwarfs any ostensible speedup you get from not having to sort. I just did a bench comparing your implementation to the previous and this new one is about 2x slower for synthetic datasets:

You can see the bench here if you're curious

[duyquang6]

very useful bench @mediocregopher
when I first use old version with aggregated hashed state to bench, the result is not good. This is why I think there something wrong with extend_ref or extend_sorted_vec

when I use your bench compare with custom own merge version (not used merge_join_by), it only shine at other target size smaller than other size, but overall case, old version still win. That give me some hint to use this function better, is keep target size and other size similar or larger so might benefit old version

shine case (new better)

but overall (size similar or target size > other) old still better

[duyquang6]

I dump the raw data of HashedPostStateSorted when bench with native-transfer

here is bench result of extend_ref, new version of both is better than in this testcase

can double check the bench here - already attach hashed state raw data
Could be raw data might have properties that benchmark doesn’t fully cover 🤔 ?