-
Notifications
You must be signed in to change notification settings - Fork 13.3k
libstd: Store capacity of std::vec::Vec on the heap? #67024
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Why just the capacity and not also the length? https://crates.io/crates/thin-vec does that. Either way, this may not be possible or desirable for
If you have specific pieces of code in mind, try changing it to use |
This was attempted with |
I would expect that the length needs to be accessed more often than the capacity, so it would be less good of a trade-off. Hard to tell without a set of reference benchmarks though. Thanks for the links, @Amanieu! Feel free to close this issue if you have reason to believe that it won't improve performance/memory consumption or just isn't worth the trouble. |
I think this is the first concern for this proposal as is. But that doesn’t mean that having some container like that isn’t worth investigating. |
The docs for
So it's possible to make this work, probably, but would also probably break lots of code in the wild. |
Given that we guarantee
https://doc.rust-lang.org/std/vec/struct.Vec.html#guarantees This is not possible |
Well, that decides it |
This has probably been discussed before but in case it hasn't: It should be possible to store a vec's capacity as part of its heap allocation and thus shrink
Vec
from three to two words. It would make a difference for code that contains many emptyVec
s and code that moves them around a lot. The downside is that the implementation is a bit more complicated and that the capacity can only be accessed after following a pointer. It might still be a worthwhile trade off.cc @rust-lang/libs (and @nnethercote who likes this kind of thing
:)
)The text was updated successfully, but these errors were encountered: