Arena: use specialization to avoid copying data

[bugadani]

In several cases, a Vec or SmallVec is passed to Arena::alloc_from_iter directly. This PR makes sure those cases don't copy their data unnecessarily, by specializing the alloc_from_iter implementation.

[rust-highfive]

r? @varkor

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

[bugadani]

cc @est31

[varkor]

Apologies for taking so long; this slipped under my radar. I'm not familiar with this code, so I'm assigning to @Mark-Simulacrum based on git blame.

r? @Mark-Simulacrum

[bugadani]

@Mark-Simulacrum I've done what I could. I've addressed your comments and reverted some changes based on those comments. For example, changes to write_from_iter are no longer part of this PR, as they aren't necessary any more.

[Mark-Simulacrum]

@bors try @rust-timer queue

This should just be a win (or roughly neutral), but let's check. r=me otherwise.

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 43b83b334130ef066d8518ca2a125779399ccd73 with merge aa21b48c4d75183274998a446bae14e98053637a...

[bors]

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

[rust-timer]

Queued aa21b48c4d75183274998a446bae14e98053637a with parent c9c57fa, future comparison URL.

[rust-timer]

Finished benchmarking try commit (aa21b48c4d75183274998a446bae14e98053637a): 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 modify labels: +S-waiting-on-review -S-waiting-on-perf

[bugadani]

Interesting. I wonder if I see the results correctly - an increase in instruction counts, but in the same time, looking at the detailed results, a decrease in times? For example, this report belongs to a 0.5% instruction count regression, but shows a -0.3% total time diff: https://perf.rust-lang.org/detailed-query.html?commit=aa21b48c4d75183274998a446bae14e98053637a&base_commit=c9c57fadc47c8ad986808fc0a47479f6d2043453&benchmark=match-stress-enum-check&run_name=incr-unchanged

Hmm.

[Mark-Simulacrum]

I would say that this is perhaps a slight regression in instruction counts, but overall a win on cycles -- https://perf.rust-lang.org/compare.html?start=c9c57fadc47c8ad986808fc0a47479f6d2043453&end=aa21b48c4d75183274998a446bae14e98053637a&stat=cycles%3Au on non-incremental benchmarks. I am inclined to land it based on these performance results; it does not seem like an obvious win yet, but it does seem like something we should be doing to try and avoid potential problems for the cases optimized here.

[Mark-Simulacrum]

Ok, r=me with commits squashed

[Mark-Simulacrum]

@bors r+

[bors]

📌 Commit e93a463 has been approved by Mark-Simulacrum

[est31]

Are the cycle numbers always this noisy? There is a 5% on incr-unchanged on the encoding-check benchmark. Apparently most of the slowdown comes from early_lint_checks being 50% slower. https://perf.rust-lang.org/detailed-query.html?commit=aa21b48c4d75183274998a446bae14e98053637a&base_commit=c9c57fadc47c8ad986808fc0a47479f6d2043453&benchmark=encoding-check&run_name=incr-unchanged

Should this worry us?

[Mark-Simulacrum]

Note that the 50% there is a wall clock measurement of 6ms, which is almost certainly noise. Cycle measurements frequently have noise in the 5% range on clean benchmarks; for incremental unchanged benchmarks they can be even noisier since there's less overall cycles on those.

I am not particularly worried.

[est31]

@Mark-Simulacrum thanks for the info!

[bors]

⌛ Testing commit e93a463 with merge 432d116...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 432d116 to master...

[rust-highfive]

📣 Toolstate changed by #78569!

Tested on commit 432d116.
Direct link to PR: #78569

💔 rls on linux: test-pass → test-fail (cc @Xanewok).

[pickfire]

Looks like there are quite a bit of code duplication here, shouldn't it be refactored?

[bugadani]

Well, it's not intentionally duplicated, but I couldn't find a way to make it significantly nicer. Unfortunately, we can't use alloc_from_slice because it requires the items to be Copy.