You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So far, when we grow the array in a BitmapIndexed, we nearly always enhance it by one (the one exception is union*). For each of these enhancements, we allocate a fresh array and copy over the elements from the old one.
It may be more efficient to grow these array by a factor of 2 or 1.5 instead, avoiding the allocations and copying for some of the enhancements. The unused slots at the end of the array could be marked with Empty or a dedicated Placeholder element. Wherever we rely on the length of the array, we could use the popcount of the bitmap instead.
If we don't want to have the unused array slots using up memory and GC-time, we could limit this array growth strategy to certain functions like fromList and follow up with a pass that removes the excess space with shrinkSmallMutableArray# (#362).
So far, when we grow the array in a
BitmapIndexed
, we nearly always enhance it by one (the one exception isunion*
). For each of these enhancements, we allocate a fresh array and copy over the elements from the old one.It may be more efficient to grow these array by a factor of 2 or 1.5 instead, avoiding the allocations and copying for some of the enhancements. The unused slots at the end of the array could be marked with
Empty
or a dedicatedPlaceholder
element. Wherever we rely on the length of the array, we could use the popcount of the bitmap instead.Regarding the ideal growth factor, there is some discussion in https://stackoverflow.com/q/1100311/1013393.
The text was updated successfully, but these errors were encountered: