6 ms·
Does slotmap shrink and reclaim allocated memory when most of the elements it stores get deleted?
by kubb 5y ago
Does slotmap shrink and reclaim allocated memory when most of the elements it stores get deleted?
- cyber_kinetist 5y agoYes, if you use the dense version of it (DenseSlotMap). It requires an additional indirection per lookup, but makes up for the fact that it’s much cache friendlier. From looking at a simple benchmark (https://www.reddit.com/r/rust/comments/gfo1uw/benchmarking_slotmap_slab_stable_vec_etc https://www.reddit.com/r/rust/comments/gfo1uw/benchmarking_s...) it seems that insertion/deletion gets a hit but accesses are faster (although YMMV on real world use cases)
- orlp 5y agoThis reddit post is such a shame, and I wish people would stop referring to it. The benchmarking code is not apples to apples at all in many places. E.g. to benchmark removals they used `container.remove(index)` for data structures that support indices but for slotmap they used `slotmap.remove(keys[index])` which unfairly adds another layer of indirection.
- nightcracker 5y agoSlotMap literally cannot, because it must keep track of versions of the used slots, and the slots include the memory space for the data. DenseSlotMap sort of can. It still can't reclaim the memory used by empty slots for the same reason (at a cost of 8 bytes per slot), but can reclaim the memory used by the actual elements stored. So if you store 1 million items at one point in a DenseSlotMap, and then clear them all and then shrink to fit (which is actually missing from the API, but I'll fix that soon) you will waste 7.6 megabytes on the empty slots but nothing on the actual data that used to be stored.