extract code path shared between FromIterator and Extend

[the8472]

This should eliminate the call to reserve on the FromIterator code path since that's redundant after the with_capacity call. So it should result in reduced IR.

I hope this will result in better compile times by itself, but if not it may still improve the numbers combined with the revert in #83797 which would increase the code weight of reserve()

@rustbot label T-libs-impl

[rust-highfive]

r? @kennytm

(rust-highfive has picked a reviewer for you, use r? to override)

[bjorn3]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 3106144c936d272948ff0b8810fed5631313b3c5 with merge ac90c16857e21ef6d6b1345ef9256dce98e9fe32...

[bors]

☀️ Try build successful - checks-actions
Build commit: ac90c16857e21ef6d6b1345ef9256dce98e9fe32 (ac90c16857e21ef6d6b1345ef9256dce98e9fe32)

[rust-timer]

Queued ac90c16857e21ef6d6b1345ef9256dce98e9fe32 with parent 2faef12, future comparison URL.

[rust-timer]

Finished benchmarking try commit (ac90c16857e21ef6d6b1345ef9256dce98e9fe32): 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
@rustbot label: +S-waiting-on-review -S-waiting-on-perf

[bors]

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

[bors]

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

[bors]

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

[JohnTitor]

Has something been changed after reverting #83770? I'm seeing #83770 (comment) and would like to know if we should re-run a perf-check.

[kennytm]

lgtm, but let's perf again if we have concern.

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 32e5469d7eaea4af7d07d2ae2fad85571eb99611 with merge 5f36abf9c680c844c0922aba74bf53de36c196df...

[bors]

☀️ Try build successful - checks-actions
Build commit: 5f36abf9c680c844c0922aba74bf53de36c196df (5f36abf9c680c844c0922aba74bf53de36c196df)

[rust-timer]

Queued 5f36abf9c680c844c0922aba74bf53de36c196df with parent cd8b56f, future comparison URL.

[rust-timer]

Finished benchmarking commit (5f36abf9c680c844c0922aba74bf53de36c196df): comparison url.

Summary: This change led to moderate relevant mixed results 🤷 in compiler performance.

• Small improvement in instruction counts (up to -0.6% on incr-unchanged builds of ripgrep)
• Moderate regression in instruction counts (up to 2.2% on full builds of regex)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf +perf-regression

[the8472]

let's see if this is due to changes in inlining.

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

[bors]

⌛ Trying commit 7f904fb with merge ba1a6f780e8a742e9ef7c9ad17635f9dc05e173b...

[bors]

☀️ Try build successful - checks-actions
Build commit: ba1a6f780e8a742e9ef7c9ad17635f9dc05e173b (ba1a6f780e8a742e9ef7c9ad17635f9dc05e173b)

[rust-timer]

Queued ba1a6f780e8a742e9ef7c9ad17635f9dc05e173b with parent 1af55d1, future comparison URL.

[rust-timer]

Finished benchmarking commit (ba1a6f780e8a742e9ef7c9ad17635f9dc05e173b): comparison url.

Summary: This change led to moderate relevant mixed results 🤷 in compiler performance.

• Small improvement in instruction counts (up to -0.5% on incr-unchanged builds of ripgrep)
• Moderate regression in instruction counts (up to 2.0% on full builds of regex)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: +S-waiting-on-review -S-waiting-on-perf +perf-regression

[the8472]

Looks like it's no longer worth it.