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.


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Reply via email to