-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Feature: more control over container (eg. Vec) capacities #49385
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
Could you please show some use cases for this? They are also probably going to be useful as examples in the documentation. |
@leonardo-m the example that spurred this issue was this: |
@Diggsey, to play devil’s advocate, wouldn’t it be better to release the entire |
@vitalyd Indeed, that is my preferred way of reducing the capacity. |
@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 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. |
@Diggsey, ok - I didn’t know allocation is expensive in webassembly. The # of allocations doesn’t have to be 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. |
One or more valid use cases are required to consider adding any feature/function to std. |
Implement `shrink_to` method on collections Fixes rust-lang#49385
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.
The text was updated successfully, but these errors were encountered: