Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vec::append should swap if the lhs is empty #56763

Open
Gankra opened this issue Dec 13, 2018 · 2 comments
Open

Vec::append should swap if the lhs is empty #56763

Gankra opened this issue Dec 13, 2018 · 2 comments
Labels
I-slow Issue: Problems and improvements with respect to performance of generated code. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@Gankra
Copy link
Contributor

Gankra commented Dec 13, 2018

Here's a reasonable pattern:

let mut results = Vec::new();
for ... {
  results.append(new_results);
}

On the first append, we can just swap ourselves with the rhs, avoiding an allocation and copy. This is annoying for our users to remember to do, and is basically free to support given how much work this method otherwise does.

It should perhaps only be done if lhs.capacity is 0, just because we don't want to mess up a user who has preallocated a nice big buffer. Maybe lhs.capacity < rhs.capacity?

@estebank estebank added I-slow Issue: Problems and improvements with respect to performance of generated code. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Dec 13, 2018
@petertodd
Copy link
Contributor

Nit: lhs.capacity() <= rhs.capacity() should be fine. :)

Though I could imagine this causing problems in conjunction with Vec::from_raw_parts() in unusual cases where the code had done something special with the allocation of the lhs.

@the8472
Copy link
Member

the8472 commented Oct 23, 2020

I attempted implementing this in #77538 but it didn't seem to have any measurable impact on compiler performance. Is there any known codebase where we would expect this to be beneficial? If not perhaps the issue can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I-slow Issue: Problems and improvements with respect to performance of generated code. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants