I was talking to a friend today about using Arc<[u8]> instead of Arc<Vec<u8>> and we went down the rabbit hole of how this works under the hood.

It's clear that this will always allocate new memory for the data, copy the Vec's data to the new mem, and deallocate old memory. We were trying to figure out if there's a way to reasonably reuse the Vec's data pointer and eliminate copying the data (and at this time this is just a thought experiment -- not something actually killing perf).

Note, I haven't dug deep into the inner-workings of Arc, but I believe that the root of the issue is that the layout of ArcInner obviously is not the same as the layout of Vec's data. At the time of writing, ArcInner is:

#[repr(C, align(2))]
struct ArcInner<T: ?Sized> {
   strong: Atomic<usize>,

   // the value usize::MAX acts as a sentinel for temporarily "locking" the
   // ability to upgrade weak pointers or downgrade strong ones; this is used
   // to avoid races in `make_mut` and `get_mut`.
   weak: Atomic<usize>,

   data: T,
}

So even if the Vec had enough unused capacity to accommodate the strong/weak pointers, a copy would still be needed to push the data forward and the fields cannot be reorganized because of the ?Sized constraint and the pointer arithmetic to reach the strong/weak counts would slow things down.

I suppose that the pointer to the data could be stored instead, but now you're chasing pointers which outside of this niche case might hurt perf more overall.

This is all a long way of asking if there are any practical means of eliminating this copy specifically for From<Vec<T>> or at least the allocation? Or does this just unnecessarily complicate code for one particular optimization path which may be negated by side effects of re-architecting specifically for the optimization (pointer chasing)?

6 posts - 6 participants

Read full topic