Pin the number of frontend threads while gathering PGO to 1

[Kobzol]

This will be important after rust-lang/rustc-perf#2574 is synced here, to avoid running some benchmarks multiple times unexpectedly.

But we can do it proactively, the CLI argument should already be in the in-tree rustc-perf version (hopefully, let's see).

[Kobzol]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: a64f96d (a64f96de799ffa629d4a70cbd84ef42e51386e9b)
Base parent: 656a9da (656a9da186dacaf3bf8f7f7296a825d256cb4ae3)

[rust-timer]

Finished benchmarking commit (a64f96d): comparison URL.

Overall result: ❌ regressions - 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.3%	[0.2%, 0.4%]	7
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

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%	[4.4%, 6.9%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Cycles

Results (primary -0.6%, secondary 2.7%)

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

	mean	range	count
Regressions ❌ (primary)	0.7%	[0.5%, 0.9%]	6
Regressions ❌ (secondary)	2.7%	[2.3%, 3.1%]	2
Improvements ✅ (primary)	-3.1%	[-4.7%, -0.6%]	3
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.6%	[-4.7%, 0.9%]	9

Binary size

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

Bootstrap: 478.991s -> 479.079s (0.02%)
Artifact size: 403.45 MiB -> 403.45 MiB (0.00%)

[rustbot]

r? @jieyouxu

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

• Fallback group: @Mark-Simulacrum, @jieyouxu
• @Mark-Simulacrum, @jieyouxu expanded to Mark-Simulacrum, jieyouxu
• Random selection from Mark-Simulacrum, jieyouxu

[jieyouxu]

Thanks, r=me unless we're waiting for anything else.

[jieyouxu]

@bors r+ rollup=never note="adjusts opt-dist PGO config"

[rust-bors]

📌 Commit 731fd36 has been approved by jieyouxu

It is now in the queue for this repository.

[rust-bors]

☀️ Test successful - CI
Approved by: jieyouxu
Duration: 3h 21m 32s
Pushing a3e94c2 to main...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 6b410a8 (parent) -> a3e94c2 (this PR)

Test differences

Show 2 test diffs

2 doctest diffs were found. These are ignored, as they are noisy.

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard a3e94c2ff51d6fa9929cf637fd85df3975119801 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. test-x86_64-gnu-gcc: 56m 14s -> 1h 25m (+52.2%)
2. test-x86_64-gnu-llvm-21: 55m 41s -> 35m 11s (-36.8%)
3. dist-i686-mingw: 1h 4m -> 41m 3s (-36.2%)
4. dist-ohos-armv7: 56m 21s -> 1h 16m (+35.6%)
5. dist-x86_64-llvm-mingw: 2h 9m -> 1h 28m (-31.1%)
6. test-armhf-gnu: 1h 33m -> 1h 8m (-26.2%)
7. dist-powerpc64-linux-gnu: 1h 37m -> 1h 12m (-25.5%)
8. test-x86_64-gnu-stdlib-semver-check: 15m 4s -> 11m 34s (-23.2%)
9. test-x86_64-gnu-parallel-frontend: 1h 18m -> 1h 36m (+23.2%)
10. test-i686-gnu-nopt-2: 1h 54m -> 2h 20m (+22.9%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.