Eliminate some temporary vectors

[bugadani]

This PR changes get_item_attrs and get_item_variances to return iterator impls instead of vectors. On top of that, this PR replaces some seemingly unnecessary vectors with iterators or SmallVec, and also reserves space where we know (the minimum) number of elements that will be inserted. This change hopes to remove a few heap allocations and unnecessary copies.

[rust-highfive]

r? @davidtwco

(rust_highfive has picked a reviewer for you, use r? to override)

[Aaron1011]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit d2e31209671acb9ffccf69ac9454b5b044059238 with merge 48c4cc18598e1e0dbfe4c5dd1fe08d184ee7659b...

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: 48c4cc18598e1e0dbfe4c5dd1fe08d184ee7659b (48c4cc18598e1e0dbfe4c5dd1fe08d184ee7659b)

[rust-timer]

Queued 48c4cc18598e1e0dbfe4c5dd1fe08d184ee7659b with parent b5c9e24, future comparison URL.

[bugadani]

I've converted this to draft for now. I want to collect some more of these changes and not litter github with multiple tiny PRs just for my vec-aversion.

[rust-timer]

Finished benchmarking try commit (48c4cc18598e1e0dbfe4c5dd1fe08d184ee7659b): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never

[davidtwco]

Implementation-wise, this looks good to me. I think it makes sense to trigger another perf run since you've pushed a bunch since the last one and I'm not sure if those changes included further optimizations and be likely to impact perf.

[bugadani]

They shouldn't be hot I think, so unlikely, but I'd also prefer not merging this blindly.

[davidtwco]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit a0471227b72c89271cde11e668e66422aff90aa7 with merge d6584ef1b48dbf79269fb72ae8709b509d1f2074...

[pietroalbini]

Note: due to an infrastructure bug the try build will time out even though it completed. The underlying issue was fixed.

[pietroalbini]

@bors r- try- retry

[lcnr]

lgtm

@bors r+

[bors]

📌 Commit 6ed359c4aed753f0e988268ca477a5c6d741ee62 has been approved by lcnr

[bors]

⌛ Testing commit 6ed359c4aed753f0e988268ca477a5c6d741ee62 with merge 9dea8044ddc86503ea16c07f1ec94c4411307100...

[bors]

💔 Test failed - checks-actions

[bors]

☔ The latest upstream changes (presumably #78825) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[bugadani]

@lcnr rebased

The test failure again looks like some apple specific delight.

------------------------------------------
stderr:
------------------------------------------
error: need to add support for DW_TAG_base_type '()' encoded with DW_ATE = 0x7, bit_size = 0
clang: CommandLine Error: Option 'h' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[lcnr]

let's try again

@bors r+

[bors]

📌 Commit f0d0d87 has been approved by lcnr

[bors]

⌛ Testing commit f0d0d87 with merge a1f7ca7...

[bors]

☀️ Test successful - checks-actions
Approved by: lcnr
Pushing a1f7ca7 to master...

[nnethercote]

Nice changes. I have mentioned three of them as examples in the Rust Performance Book.