Use Arena::alloc_from_iter to avoid redundant vec allocations

[yotamofek]

Doesn't show up on my local perf run, but might improve performance by a bit in certain cases.
(second commit is a small drive-by cleanup)

[rustbot]

r? @fee1-dead

rustbot has assigned @fee1-dead.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[fee1-dead]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 49101a5 with merge 0c0943e...

[bors]

☀️ Try build successful - checks-actions
Build commit: 0c0943e (0c0943e35532070576b67897cfeb5d72df911679)

[rust-timer]

Finished benchmarking commit (0c0943e): comparison URL.

Overall result: ❌ regressions - please read the text below

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 may lead 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-perf +perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	1.1%	[1.1%, 1.1%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.1%	[1.1%, 1.1%]	1

Max RSS (memory usage)

Results (primary 0.3%, secondary 2.8%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	1.0%	[0.4%, 1.8%]	5
Regressions ❌ (secondary)	2.8%	[2.8%, 2.8%]	1
Improvements ✅ (primary)	-1.3%	[-2.2%, -0.4%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[-2.2%, 1.8%]	7

Cycles

Results (primary -0.4%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.4%	[-0.4%, -0.4%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.4%	[-0.4%, -0.4%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 772.356s -> 773.514s (0.15%)
Artifact size: 365.43 MiB -> 365.30 MiB (-0.03%)

[yotamofek]

Hmm, expected perf to be neutral at worst. That nalgebra doesn't seem spurious to me.
I'll try to see if, by process of elimination, this is caused by some of the changes but not the others.

[panstromek]

@yotamofek note that nalgebra is bimodal and is currently in the bottom state, so this might be spurious.

[yotamofek]

Ah, that makes sense, thanks!. Maybe another perf run then?

[hanna-kruppe]

Use alloc_from_iter to avoid redundant vec allocations

I don’t think this commit achieves that, the iterator in question (involving Chain and FlatMap) doesn’t have a size hint that’s usable for pre-allocating the right amount of space in the arena. But pre-allocating is necessary to avoid collecting into a Vec first. It might still be a code cleanup but if potential performance/allocations is the motivation, it seems misguided.

[yotamofek]

Use alloc_from_iter to avoid redundant vec allocations

I don’t think this commit achieves that, the iterator in question (involving Chain and FlatMap) doesn’t have a size hint that’s usable for pre-allocating the right amount of space in the arena. But pre-allocating is necessary to avoid collecting into a Vec first. It might still be a code cleanup but if potential performance/allocations is the motivation, it seems misguided.

Please correct me if I'm mistaken, but...

Both Arena::alloc_from_iter and Arena::alloc_slice have to allocate memory in the arena for the n elements they are given. If you collect into a Vec and then alloc_slice, you'll be allocating twice (of course allocating on the arena should be faster than a normal heap allocation, but still).
If you don't need to collect everything into a vector, wouldn't it be theoretically good to avoid that allocation? Doing a for loop with a Vec::push will not only disregard any size hint that could've been there, but might also cause a few heap re-allocations and copies.

[yotamofek]

Ah okay, I think what I missed was that the arena also allocates iterators into a Vec first, unless the size hint is present. So yeah, you're absolutely correct, this PR is probably misguided. Not sure if it could even be considered code cleanup.
So I should maybe close it?

(edit: specifically, the arena actually allocates into a SmallVec<[T; 8]>, which might in certain cases be helpful and might be detrimental in others)