You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Vec and VecDeque are similar in that they both use the same allocation method; they just use the allocation differently. With MaybeUninit<T::Item> and some additional ring buffer management, implementing a SmallVecDeque should be pretty simple.
The text was updated successfully, but these errors were encountered:
Assuming SmallVecDeque is implemented similarly to VecDeque, I can see a few challenges:
At least one element is always unused. For a small inline buffer, this seems wasteful.
The buffer length must be a power of two, so SmallVecDeque<usize, 10> would store either eight or sixteen inline elements. It might be better to completely forbid non-power-of-two sizes.
The capacity is one less than the buffer length. Either SmallVecDeque<usize, 3> would store four inline elements, or SmallVecDeque<usize, 4> would have an inline capacity of three. Users might unexpectedly upgrade to the next power-of-two buffer size, or unexpectedly spill from inline storage to heap storage.
It might be worth experimenting with an entirely different ring-buffer algorithm for SmallVecDeque, rather than porting VecDeque directly.
Vec
andVecDeque
are similar in that they both use the same allocation method; they just use the allocation differently. WithMaybeUninit<T::Item>
and some additional ring buffer management, implementing aSmallVecDeque
should be pretty simple.The text was updated successfully, but these errors were encountered: