Optimize SmallPersistentVector.removeAll

[mcpiroman]

Buffer elements only after the first one is removed, instead of full copy.

[qurbonzoda]

Hi @mcpiroman
Thanks for your effort.

Could you please clarify what the change optimizes? And how do they impact performance or memory footprint?

[mcpiroman]

Hi,
currently if an element to be removed is found, a N-buffer is allocated, likely filled with zeros and filled with the master buffer. This theoretically gives N*2 iterations.

With this change:

• the buffer is allocated with the size of the remaining part (after the first element to be removed), statistically this is N/2 for when single element is removed and even better when more.
• the buffer is not a copy of master, only zeroed (arrayOfNulls instead of copyOf). Currently that copy in the part-after-first-removed is unnecessary and overridden.

This should result in smaller allocation and less iterations.
It is also possible to further reduce the size by delaying the allocation to the first retained after the first removed element, to help in case multiple elements are removed in a row. This would make the code slightly more complicated I suppose.

Now, I have run the relevant tests but I haven't run benchmarks as I don't have enough CPU and personal time atm.
Would it be maybe possible to integrate benchmarks in GH workflow (example)?

[ilya-g]

currently if an element to be removed is found, N-buffer is allocated, likely filled with zeros and filled with the master buffer

The new buffer is allocated with the copyOf function, which on JVM may avoid zeroing of a newly allocated array.

So a benchmark is indeed required to confirm the performance benefit of this change.

[qurbonzoda]

Moved the review here: #164