fitzgen
commented
4 years ago Maybe it isn't clear from that comment, but the largest chunk is retained, and so given the same workload followed by a reset in a loop, the bump allocator will reach a chunk-allocation steady state after the second iteration, which seems like a good balance to me.
Additionally, one can always pre-allocate space via the with_capacity constructor.
The implementation would need to become more complicated to support retaining all chunks on reset, since we never have to handle the case where we fill a chunk and do not need to allocate a new chunk, but instead find and reuse some existing chunk. I would like to avoid such a complication unless shown overwhelming evidence that it is definitely worth it.
dbregman
comment from reset(): "/// If this arena has allocated multiple chunks to bump allocate into, then /// the excess chunks are returned to the global allocator."
It would be good to have an option to reuse all of the chunks instead of returning them to the global allocator. Perhaps the assumption of the code is that allocating chunks is cheap. This is not necessarily true for large allocations - in that case the cost is more proportional to the size of the allocation, and the number of alloc() calls becomes less relevant. e.g. 1 alloc of 1GB costs about the same as 1024 allocs of 1MB. Most of the work is in the soft page faults.