On 03/04/14 11:48 PM, Nathan Myers wrote: > >>> Perhaps the best thing is to wait a month (or two or three) until DST >>> is more of a reality and then see how we feel. >> >> Are you thinking we should also wait before converting the current uses >> of ~[T] to Vec<T>? Doing the migration gives us the performance[1] and >> zero-length-zero-alloc benefits, but there were some concerns about >> additional library churn if we end up converting back to DST's ~[T]. > > I can't speak about how a usage choice affects the standard library, > but it seems worth mentioning that vector capacity doesn't have to be > in the base object; it can live in the secondary storage, prepended > before the elements.
Needing to use a header seriously hurts the performance. The new vector is 7x faster at pushing elements when space isn't reserved compared to the old one, all due to leaving off the length/capacity header. The overhead would be less if it stored the capacity inside *and* outside the vector, but it's still overhead. It's an extra overflow check branch along with needing to calculate padding for alignment in the future, extra space in the memory allocation and more pointer aliasing issues. > A zero-length Vec<T> might be null for the case of zero capacity, > or non-null when it has room to grow. It's going to be forbidden from actually being null in the future when the Option-like enum optimization is applied to it via an attribute. This work has already landed - calling exchange_free on a zero-size allocation is *forbidden*.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
