[PERF] split dwarf benchmarking

[davidtwco]

A little perf benchmarking of Split DWARF: what impact does it have on compile times (incremental in particular), artefact sizes, etc.

r? @ghost

[davidtwco]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit eb62f83 with merge 292d5468b0b10257b2e4277ee906ab657c8308fd...

[bors]

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

[rust-timer]

Queued 292d5468b0b10257b2e4277ee906ab657c8308fd with parent d5ae66c, future comparison URL.

[rust-timer]

Finished benchmarking commit (292d5468b0b10257b2e4277ee906ab657c8308fd): comparison url.

Summary:

• Primary benchmarks: 🎉 relevant improvements found
• Secondary benchmarks: mixed results

	Regressions 😿 (primary)	Regressions 😿 (secondary)	Improvements 🎉 (primary)	Improvements 🎉 (secondary)	All 😿 🎉 (primary)
count1	2	10	14	45	16
mean2	0.8%	1.4%	-6.4%	-1.4%	-5.5%
max	1.2%	1.7%	-27.4%	-3.8%	-27.4%

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 may lead to changes in compiler perf.

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

Footnotes

1. number of relevant changes ↩

2. the arithmetic mean of the percent change ↩

[davidtwco]

I'm genuinely surprised that Split DWARF seems to have had a decent impact - I'm too used to my patches being damp squibs 😂

Lets try with packed debuginfo..

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion.

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

[bors]

⌛ Trying commit 48a29bb with merge c9bc3fa6dbc6c5f5b54055ed79bf83f15b60352c...

[bors]

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

[rust-timer]

Queued c9bc3fa6dbc6c5f5b54055ed79bf83f15b60352c with parent e2661ba, future comparison URL.

[rust-timer]

Finished benchmarking commit (c9bc3fa6dbc6c5f5b54055ed79bf83f15b60352c): comparison url.

Summary:

• Primary benchmarks: mixed results
• Secondary benchmarks: mixed results

	Regressions 😿 (primary)	Regressions 😿 (secondary)	Improvements 🎉 (primary)	Improvements 🎉 (secondary)	All 😿 🎉 (primary)
count1	8	31	8	20	16
mean2	4.2%	3.0%	-7.7%	-1.2%	-1.8%
max	6.6%	6.1%	-21.6%	-2.1%	-21.6%

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 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-review -S-waiting-on-perf +perf-regression

Footnotes

1. number of relevant changes ↩

2. the arithmetic mean of the percent change ↩

[davidtwco]

Much more mixed results from packed mode - we're losing out on some of the improvement from unpacked debuginfo, which is expected, it's always going to be strictly more work in packed mode, but I'd have hoped that it wouldn't be as much as it is - still enough for there to be some wins on larger benchmarks like ripgrep, but not enough for helloworld to be improved. I expect there's some low hanging fruit in thorin though, performance wasn't something we measured while building it.