Use real ThinVec in StmtDebugInfos

[panstromek]

View all comments

This is now possible, because thin vec has may_dangle Drop impl. Depends on #159974

[panstromek]

(mostly empty) ThinVec has slightly different performance profile compared to our poor man's thin-vec (Option<Box<Vec>>>) - empty thin vec uses a static sentinel value, whic means that reading len is branchless. There's one less branch on empty check now (previously, we needed branch on option, then branch on len). On the other hand, reading len reads some random hot 0 in static memory, which could be costlier if it's cold, compared to reading local None value.

I also changed some of the inline/outline combos in other methods, I kept it where it felt potentially useful, but I might have perturbed the performance profile because inlining is finicky.

Long story short, I want to measure this to see whether these things make some noticable difference.

@bors try @rust-timer queue

Of course, non-empty variant has one less allocation, which is good, but this is extremely rare case, so I don't worry about perf changes there.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 168b7f9 (168b7f942221b2ae2c1aac25e9a4ae3908bf981a)
Base parent: 9451e06 (9451e069c34e1d7db23a155dcf9c25d1bc127055)

[rust-timer]

Finished benchmarking commit (168b7f9): comparison URL.

Overall result: ❌ regressions - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	0.2%	[0.2%, 0.2%]	3
Regressions ❌ (secondary)	0.5%	[0.2%, 2.6%]	32
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.2%]	2
All ❌✅ (primary)	0.2%	[0.2%, 0.2%]	3

Max RSS (memory usage)

Results (primary -0.9%, secondary -4.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	1.4%	[1.4%, 1.4%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-3.2%	[-3.2%, -3.2%]	1
Improvements ✅ (secondary)	-4.1%	[-5.7%, -2.5%]	2
All ❌✅ (primary)	-0.9%	[-3.2%, 1.4%]	2

Cycles

Results (secondary 4.1%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	4.1%	[3.2%, 5.0%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

Results (primary -0.0%, secondary -0.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.0%	[-0.1%, -0.0%]	2
Improvements ✅ (secondary)	-0.0%	[-0.1%, -0.0%]	2
All ❌✅ (primary)	-0.0%	[-0.1%, -0.0%]	2

Bootstrap: 489.176s -> 489.973s (0.16%)
Artifact size: 387.73 MiB -> 387.67 MiB (-0.02%)

[panstromek]

wow, I expected some perturbation but this is surprisingly negative. Let me check the update by itself.

[panstromek]

Let's backtrack a bit and keep the option in there for now

@bors try @rust-timer queue

[panstromek]

Actually, the results here are very similar to results in #159928 (comment), so this might actually be just the thin-vec update. Let's wait for that perf run to confirm this.

[rust-bors]

☀️ Try build successful (CI)
Build commit: d58d011 (d58d0115ee77a3f917991930660a90216aa41fbd)
Base parent: dfbea5b (dfbea5bc945a9d7ff017d3d4bfbd1af9295fe5b8)

[rust-timer]

Finished benchmarking commit (d58d011): comparison URL.

Overall result: ❌ regressions - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.6%	[0.3%, 2.6%]	18
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (secondary -0.8%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.3%	[2.0%, 2.6%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.0%	[-5.7%, -2.3%]	2
All ❌✅ (primary)	-	-	0

Cycles

Results (secondary 5.6%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

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

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 486.74s -> 496.176s (1.94%)
Artifact size: 387.74 MiB -> 387.80 MiB (0.02%)

[panstromek]

ok, the new-solver changes are due to ThinVec update, but apart from that, the second perf run looks better, so let's keep the Option there. We'll figure the new-solver regressions in #159974

@rustbot blocked

[panstromek]

Let's recheck after the update has landed separately, now we should get proper results.

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 8f0457f (8f0457fb81b1227f0956aa76be0a7edf462a1b80)
Base parent: e19d321 (e19d321c06479c6fd77533582b0d5a86651f1be3)

[rust-timer]

Finished benchmarking commit (8f0457f): comparison URL.

Overall result: ❌✅ regressions and improvements - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

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

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

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

Max RSS (memory usage)

Results (primary -1.2%, secondary -2.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.2%	[-1.2%, -1.2%]	1
Improvements ✅ (secondary)	-2.3%	[-3.7%, -0.9%]	3
All ❌✅ (primary)	-1.2%	[-1.2%, -1.2%]	1

Cycles

Results (primary -1.5%, secondary -2.3%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.5%	[2.9%, 4.1%]	2
Improvements ✅ (primary)	-1.5%	[-1.5%, -1.5%]	1
Improvements ✅ (secondary)	-4.6%	[-6.4%, -3.1%]	5
All ❌✅ (primary)	-1.5%	[-1.5%, -1.5%]	1

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 490.165s -> 489.018s (-0.23%)
Artifact size: 388.34 MiB -> 391.12 MiB (0.71%)

[panstromek]

The include-blob is its classic noise. This looks ok now.

@rustbot label: +perf-regression-triaged

[panstromek]

fixed tidy

[rustbot]

r? @davidtwco

rustbot has assigned @davidtwco.
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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler, mir
• compiler, mir expanded to 74 candidates
• Random selection from 18 candidates