Should we not enlarge PagedGrowableWriter initial bitPerValue on NodeHash.rehash()?

[dungba88]

Description

Spawn from #12738

It seems on rehash we will use an initial bitPerValue set to cover the last node address.

Does that mean every values, including the ones with low-address will use the same bpv as the high-address nodes? PagedGrowableWriter already enlarge the bpv automatically, so maybe we could always set the initial bpv to a small value (like 8?)

Let see if the total size is different when making the change

Version and environment details

No response

[dungba88]

I think this should be enhancement instead of bug, but I can't edit it. @mikemccand can you help to change the label?

[mikemccand]

I think this should be enhancement instead of bug, but I can't edit it. @mikemccand can you help to change the label?

Done. Annoying that GH won't let you do that, especially when you are the one who opened it!

[mikemccand]

Does that mean every values, including the ones with low-address will use the same bpv as the high-address nodes? PagedGrowableWriter already enlarge the bpv automatically, so maybe we could always set the initial bpv to a small value (like 8?)

OK so I think normally PagedGrowableWriter would indeed be more compact if earlier values used smaller bpv than later values, and the paging was small enough so that there were enough pages to have separate mutables with different bpv?

But in our usage here as a hash table, the inputs will more or less randomly scatter across the pages to the point where all pages will soon have to update to the large (current) bpv on insert anyways?