Change:
} } <del> let mut gap = FillGapOnDrop { read: 1, write: 1, vec: self }; let ptr = gap.vec.as_mut_ptr(); </del> /* Drop items while going through Vec, it should be more efficient than * doing slice partition_dedup + truncate */ <ins> // Construct gap first and then drop item to avoid memory corruption if `T::drop` panics. let mut gap = FillGapOnDrop { read: first_duplicate_idx + 1, write: first_duplicate_idx, vec: self }; unsafe { // SAFETY: we checked that first_duplicate_idx in bounds before. // If drop panics, `gap` would remove this item without drop. ptr::drop_in_place(start.add(first_duplicate_idx)); } </ins> /* SAFETY: Because of the invariant, read_ptr, prev_ptr and write_ptr * are always in-bounds and read_ptr never aliases prev_ptr */ unsafe { while gap.read < len { <del> let read_ptr = ptr.add(gap.read); let prev_ptr = ptr.add(gap.write.wrapping_sub(1)); </del> <ins> let read_ptr = start.add(gap.read); let prev_ptr = start.add(gap.write.wrapping_sub(1)); </ins> <del> if same_bucket(&mut *read_ptr, &mut *prev_ptr) { </del> <ins> // We explicitly say in docs that references are reversed. let found_duplicate = same_bucket(&mut *read_ptr, &mut *prev_ptr); if found_duplicate { </ins> // Increase `gap.read` now since the drop may panic. gap.read += 1; /* We have found duplicate, drop it in-place */ ptr::drop_in_place(read_ptr); } else { <del> let write_ptr = ptr.add(gap.write); </del> <ins> let write_ptr = start.add(gap.write); </ins> <del> /* Because `read_ptr` can be equal to `write_ptr`, we either * have to use `copy` or conditional `copy_nonoverlapping`. * Looks like the first option is faster. */ ptr::copy(read_ptr, write_ptr, 1); </del> <ins> /* read_ptr cannot be equal to write_ptr because at this point * we guaranteed to skip at least one element (before loop starts). */ ptr::copy_nonoverlapping(read_ptr, write_ptr, 1); </ins> /* We have filled that place, so go further */ gap.write += 1;

Discussion:
It seems like the implementation makes two passes over the data, making many more copies than are strictly necessary. Doing this allows the implementation to panic without causing a leak. I wouldn't call this bad, but it was a surprise to see that it was doing the extra work. Mimicking the way handles this and temporarily shortening the vector allows us to cut down on the copies (and also conveniently removes a panicking branch). I wonder if it makes sense to document the trade-off that makes here? Imo, it'd make it easier to use the library correctly in the way that
I wonder if it would be even faster to split it into two loops since once it will always be hitting that branch in the loop to do ? Maybe it could help reduce branch misprediction? I feel like this could be applied to the same thing right now. I wonder why are we not using but instead use ? And do we really need to , from what I see it does not do that right now? cc who may be interested in this.
The leaking behavior is unnecessary. A drop guard handle the tail.
is being called in in the current implementation. If you''re asking why I'm using , it's because it's faster than , and we don't need to use in this implementation. I'm pretty sure you're right My mistake, I wound myself up trying to justify the call. I think that means this would be a direct upgrade to the current implementation? (Note: My implementation seems to be broken in a couple ways, it's just for reference)
I tried to flesh out the implementation a little, and make sure it's working properly. The behaviour of the still needs to be tested, and it'd be good to do a more thorough benchmark if this was being considered for addition. I also implemented the nested loop version. I can't tell if it helped with performance yet, since my computer gives the benchmarks too much noise.
Do you think separating the branch into a different loop is a good idea in case they are not in the same bucket?
I've used a second (and third) loop in the implementation to avoid the branch, did I misunderstand your recommendation?
It still does seemed to be in the loop , I think making that in the inner loop is the same as the one currently since that branch will always be there.

I didn't benchmark and I am not sure if it will be faster, just a guess avoiding that branch may end up reducing branch mispredictions.
:thinking: I honestly don't know how I'd implement that - it seems like we need to branch somewhere to verify the the copies are legal. I'd welcome a PR showing what you mean.
I mean we are branching it in another loop since once the dedup and is different, it will always copy stuff when it hit the other branch, so instead of having 2 branches when the bucket is different, we could keep it to the other loop to remove the branch. Not sure if it's faster though.
proposed additional optimizations for this issue. Details here: