VecDeque<u8> used as a fifo.
What I really need here is truncate_front() after I copied nbytes of u8 bytes from the slice(s) returned by as_slices(), but it isn't stabilized yet.
So I did the following, hoping that it would achieve similar performance:
let drain = fifo.drain(0..nbytes);
drop(drain);
Am I right that the performance should be similar?
Depending on what your goal is: maybe?
I don't know what the corresponding len argument to truncate_front() would be and what the rest of the program entails. You can compare the assembly generated by both implementations on godbolt.
Depending on your use case, you may also want to use a ring buffer.
VecDeque is already implemented as a ring buffer:
A double-ended queue implemented with a growable ring buffer.
Looks fine to me: https://rust.godbolt.org/z/eK8G6ErYb.
No loops, just some checks to handle the various possibilities that occur from it being a ring buffer. (Vec truncate is simpler because it doesn't need to handle the wrapping cases.)
Yes, but the description of OP indicated to me, that they want a fixed-capacity ring buffer. Why else truncate it?
Your comment doesn't make any mention of "fixed-capacity" nor does the link you supplied. You simply stated
Depending on your use case, you may also want to use a ring buffer
as though VecDeque is not a ring buffer. Of course elsewhere in the crate documentation you linked, it does mention "fixed-capacity"; but that was not at all clear from your comment. I'd recommend at least editing your comment so that a "fixed-capacity" modifier precedes "ring buffer" to make your intent clear.
Thanks!
I learned at the uni that a ring buffer, per definition, is always fixed-size. The Wikipedia article agrees on that: Circular buffer - Wikipedia
Interesting, but there seems to be some lack of consensus that ring buffer requires a fixed capacity so it wouldn't hurt to add the fixed-capacity modifier to clear up any ambiguity. If not, feel free to submit a PR to change the description of VecDeque such that it doesn't call itself a "growable ring buffer" on the grounds that the description is a contradiction since ring buffer requires fixed-capacity.
This seems to be one of the many cases where people disagree on the meaning of a word; and instead of insisting one definition is the "correct" one, just make it clear which one you are using. Even in rigorous fields like pure math, you're going to find a collisions of terms; and it's not a problem because the chosen definition is stated or at least clarified upon any confusion that arises.
I think it's not worth it. They specifically added the attribute "growable" to emphasize that it differs from the academic definition. And I believe that we have digressed enough into nomenclature debate in this already solved thread. 
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.