Closed
Conversation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR inspired by noticing that the following, while it seems reasonable, actually contains 4 calls to
reservein the ASM:https://rust.godbolt.org/z/EWExYP
Like there's
extend_from_slicefor cloning, it seems like it would be logical to have anextend_from_arrayto encapsulate the obviousunsafecode for moving the elements to the end of the vector. And, indeed, that turns out to generate tighter assembly than any of the other options I tried, includingarray::IntoIterandchains-of-onces: https://rust.godbolt.org/z/Wq7qahI ended up putting this on
Extend, as it makes particular sense on anything that can take advantage of the memory continuity of the array -- this PR implements it forVecandVecDeque-- but would also be handy as a way to tersely add a known number of elements to any collection by move. It has the nice default implementation in terms of the arrayIntoIter, so that things without special overrides for it can still do something reasonable, as that provides an exactsize_hint.But touching a trait means it should probably get some libs eyes on it even to go in unstable, so let's try
r? @m-ou-se
(A different approach for this could be something like
push_chunk, in the sense ofas_chunks.)