Exhaustiveness: allocate memory better

[Nadrieril]

Exhaustiveness is a recursive algorithm that allocates a bunch of slices at every step. Let's see if I can improve performance by improving allocations.

Already just using Vec::with_capacity is showing impressive improvements on my local measurements.

r? @ghost

[Nadrieril]

@bors try @rust-timer queue

[bors]

⌛ Trying commit ab2a92a with merge 73621b2...

[bors]

☀️ Try build successful - checks-actions
Build commit: 73621b2 (73621b2741228d97b378a2824e61f1798b8634f5)

[rust-timer]

Finished benchmarking commit (73621b2): comparison URL.

Overall result: ❌✅ regressions and improvements - ACTION NEEDED

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 a highly reliable metric that was used to determine the overall result at the top of this comment.

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

Max RSS (memory usage)

Results

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)	2.0%	[2.0%, 2.0%]	1
Regressions ❌ (secondary)	2.4%	[1.5%, 5.0%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.0%	[2.0%, 2.0%]	1

Cycles

Results

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)	3.7%	[3.0%, 4.3%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 674.191s -> 671.744s (-0.36%)
Artifact size: 313.41 MiB -> 313.42 MiB (0.00%)

[Nadrieril]

I am so disappointed x) I had >5% improvements on cycles for unicode_normalization and html5ever in my local measurements

[Nadrieril]

Alright, more ideas

@bors try @rust-timer queue

[bors]

⌛ Trying commit eee8baf with merge c0020fd...

[bors]

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

[bors]

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

[the8472]

I am so disappointed x) I had >5% improvements on cycles for unicode_normalization and html5ever in my local measurements

Make sure to enable jemalloc when testing allocation-related stuff locally.

[rust-timer]

Finished benchmarking commit (c0020fd): comparison URL.

Overall result: ✅ improvements - no action needed

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.

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

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.5%	[-3.8%, -3.2%]	6
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results

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)	4.8%	[4.8%, 4.8%]	1
Improvements ✅ (primary)	-2.5%	[-2.5%, -2.5%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.5%	[-2.5%, -2.5%]	1

Cycles

Results

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)	6.7%	[5.5%, 8.4%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

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

Bootstrap: 672.931s -> 673.492s (0.08%)
Artifact size: 313.36 MiB -> 313.39 MiB (0.01%)

[Nadrieril]

Yep, using jemalloc. That's what I got for this commit 🥲 (on u:cycles)

Is it that CI uses a very different architecture? Or that PGO correctly predicted the allocations in such a way that my changes don't matter? We'll never know...

[Nadrieril]

@nnethercote what do you think of this? I seem to be doing something right but CI perf is totally unmoved by it (ignore match-stress, it naturally doesn't like that I over-allocate in pop_head_constructor; I should remove that).

[nnethercote]

I usually assume differences in local perf vs CI perf are de to PGO and/or BOLT. It can be opaque, certainly.

Are you on Linux? If so, you can measure allocations with DHAT, which can be useful.

[Nadrieril]

Hm, I have a pretty clear idea of allocation behavior; what I find difficult is to know what a typical match statement looks like so I can optimize for that. Since CI can't help me, I'll just keep the changes that are unambiguously good.

[Nadrieril]

Thank you!

@bors r=@nnethercote

[bors]

📌 Commit c1774a1 has been approved by nnethercote

It is now in the queue for this repository.

[bors]

⌛ Testing commit c1774a1 with merge 53ded39...

[rust-log-analyzer]

The job armhf-gnu failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[bors]

💔 Test failed - checks-actions

[Nadrieril]

That looks spurious

@bors retry

[bors]

⌛ Testing commit c1774a1 with merge 80a897a...

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[bors]

💔 Test failed - checks-actions

[Nadrieril]

Spurious again (Too Many Requests from the docker registry)

@bors retry

[bors]

⌛ Testing commit c1774a1 with merge cf8d812...

[bors]

☀️ Test successful - checks-actions
Approved by: nnethercote
Pushing cf8d812 to master...

[rust-timer]

Finished benchmarking commit (cf8d812): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

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

Max RSS (memory usage)

Results

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)	3.8%	[3.8%, 3.8%]	1
Regressions ❌ (secondary)	2.8%	[2.2%, 3.3%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	3.8%	[3.8%, 3.8%]	1

Cycles

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

Binary size

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

Bootstrap: 673.692s -> 673.967s (0.04%)
Artifact size: 314.13 MiB -> 314.12 MiB (-0.00%)