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.
Perhaps I am not understanding you correctly. Assuming that the capacity
is stored inside and outside Vec, the only overhead
I see is during allocation/deallocation. Otherwise the code will be
identical. If you are worried about space, there is a cost of
passing around Vecs ( vs ~[T]), which consumes and extra register for
the capacity.
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*.
As mentioned elsewhere on this thread, we can use another invalid
pointer value to represent
either Option-None or 0 capacity depending on which is more efficient.
Manu
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
