On 03/04/14 02:15 AM, comex wrote: > On Wed, Apr 2, 2014 at 9:21 PM, Daniel Micay <danielmi...@gmail.com> wrote: >> I used a sentinel value in my fix along with providing a guarantee that >> `free` is never called on zero-size allocation. That's the end of any >> no-op `Vec<T>` -> `~[T]` conversions since it will need to free a zero >> size allocation. It's not far from just calling `shrink_to_fit`, and >> allowing for passing a size to `free`. >> >> https://github.com/mozilla/rust/pull/13267 > > I see the benefit of free knowing the size in this case, although it > seems that it would strongly call for type-level integers to avoid > needing a special case in the compiler.
I'm not sure how type-level integers help. This size is often a dynamic one and this doesn't involve any special cases in the compiler. The conversion between Vec<T> and ~[T] is entirely a library feature. > I don't think this issue necessarily guarantees Vec<T> can't be freely > converted to ~[T]. You could hypothetically special case allocations > for zero-sized types, while keeping all other allocations real > (including zero sized, since the impact would be minimal). Vec<T> won't be convertible to ~[T] with a no-op after the fix for `Some(~())` lands: https://github.com/mozilla/rust/pull/13267 It will need to free the allocation if it is zero-size. Calling `shrink_to_fit()` isn't far from that and allows passing the length to the free function. Extending the Option-like enum optimization to other types like `Rc<T>` and `Vec<T>` is planned so this issue applies to them too. >> You're talking about allocators designed around the limitation of an >> API. The design no longer needs to make the same compromises if you're >> going to know the size. The difference between no cache miss and a cache >> miss is not insignificant... > > I explained why I think a chunk header is necessary in any case. > Maybe it is still a significant win. The C++14 proposal claims Google > found one with GCC and tcmalloc, although tcmalloc is rather > inefficient to start with... I would like to see numbers. > > Then again, I agree with the other reasons that using ~[T] is a bad > idea, so I have no particular reason to disagree with having the size > parameter either.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev