nit: Please add a whitespace between // and the comment. Same bellow.

This heuristic is different from the proposed idea in #71. It still honours only "visible" entries in deciding when to compact; and so it is susceptible to the same problem. The idea that was proposed is that we should instead track the full allocated size of the underlying slice.

This heuristic also seems different from the original: it checks the ratio of stable entries vs. cap; previously it checked the ratio of all entries vs. cap. Any particular reason why you went with this heuristic?

hi @pavelkalinnikov, thanks for the review
I forgot that cap() considers the backing array only for the last index, not the beginning one

I had another thought - at the time of shrinking the entries slice, if we remove references to the shrunk pb.Entry elements, then two things will happen:

1. with no more references, the 'shrunk' pb.Entry values will immediately become available for GC (if not in use)
2. the append() method will consider creating an entirely new backing array at the time of adding new elements when capacity is low, and then the preceding unreachable values (which currently hold empty pb.Entry values after the above change) will also become available for GC

this seemed like a much cleaner solution to me

if this approach seems feasible, then we can optimise the design further by replacing pb.Entry values with pointers instead, to further minimise the memory cost of holding shrunk values in the array until append() replaces the backing array

hi @pavelkalinnikov, could you please share your review of the above approach?