Feature: more control over container (eg. Vec) capacities

[Diggsey]

Currently there is only one way to reduce the capacity of a Vec without clearing it completely: vec.shrink_to_fit()

However, often more control is needed. For example, it's common to want to shrink the capacity, but not below some threshold, eg. vec.shrink_to(MIN_CAPACITY).

There are probably other cases where you would want to be able to more directly control the capacity too.

[leonardo-m]

Could you please show some use cases for this? They are also probably going to be useful as examples in the documentation.

[Diggsey]

@leonardo-m the example that spurred this issue was this:
I use a VecDeque to queue events to be processed. If the queue goes under-utilised for a period of time, then I'd like to shrink the capacity of the queue to avoid wasting memory. However, just because there are no events in the queue right now doesn't mean I want to shrink the capacity to zero: I just want to reduce the capacity to some new estimate of the maximum length of the queue in the immediate future.

[vitalyd]

@Diggsey, to play devil’s advocate, wouldn’t it be better to release the entire Vec back to the allocator and then, when an element comes, alloc a new one to MIN_CAPACITY? That way all of its memory could be used in the meantime. Or are you worried about the latency of getting that fresh allocation? However, the fact the Vec grew above MIN_CAPACITY would imply it may again, and another allocation would happen anyway.

[Pauan]

@vitalyd Indeed, that is my preferred way of reducing the capacity.

[Diggsey]

@vitalyd this is on webassembly where allocation is relatively expensive but memory is still quite cheap.

If I'm averaging a lot of events, then keeping the capacity of the queue high makes sense, otherwise I'd have to perform log(n) allocations on every iteration.

Note: I'm only reducing the capacity if the queue utilization stays below 50% for an extended period, the goal being to save memory if there was a sudden burst of events (such as on page load) and we don't want to keep around a huge queue forever if it's going to waste.

[vitalyd]

@Diggsey, ok - I didn’t know allocation is expensive in webassembly.

The # of allocations doesn’t have to be log(N) - if you were to release the whole allocation, you could be more aggressive with MIN_CAPACITY (or perhaps INIT_CAPACITY would be more appropriate). I think you’re already in heuristics territory so playing with these numbers could strike a nice balance for avg workloads.

But, you know your usecase better than I. I think the proposed change stands on its own conceptual ground and doesn’t really need a specific motivating example. Thanks for entertaining my questions.

[leonardo-m]

I think the proposed change stands on its own conceptual ground and doesn’t really need a specific motivating example.

One or more valid use cases are required to consider adding any feature/function to std.