(EXPERIMENT) Perf experiments for target-machine command-line quoting #146804

Zalathar · 2025-09-20T03:55:56Z

This works because the only characters we care about escaping are ASCII characters, so forwarding non-ASCII UTF-8 bytes as-is still produces correct results.

r? ghost

Zalathar · 2025-09-20T03:57:02Z

@bors try @rust-timer queue

(EXPERIMENT) Perform target-machine command-line quoting as bytes, not characters

rust-bors · 2025-09-20T06:08:31Z

☀️ Try build successful (CI)
Build commit: 515de9c (515de9cd3470057d08f216bc055bf2a2236db0c0, parent: ec38671075266e9cee0348701da2e133379e7c6c)

rust-timer · 2025-09-20T07:19:07Z

Finished benchmarking commit (515de9c): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@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
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-1.7%	[-8.2%, -0.3%]	8
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

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

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: 470.599s -> 471.807s (0.26%)
Artifact size: 389.97 MiB -> 389.89 MiB (-0.02%)

Zalathar · 2025-09-20T10:18:42Z

I'm going to recycle this PR for a few related perf experiments.

Ironically, benchmarking these changes is only possible because we prepare quoted command-line arguments for all targets, even though the string only gets used for generating PDBs.

@bors try @rust-timer queue

(EXPERIMENT) Perf experiments for target-machine command-line quoting

Zalathar · 2025-09-20T10:24:20Z

There's a more general problem that producing this command-line string makes target_machine_factory relatively expensive, but there are a few callers that treat it as cheap.

It would be nice to build the string at most once per rustc, but we'd have to figure out where to put the necessary mutable state.

rust-bors · 2025-09-20T12:30:14Z

☀️ Try build successful (CI)
Build commit: 09a6b1d (09a6b1dbdadd53e80e5fc085caefd7d23daf7793, parent: e4b521903b3b1a671e26a70b9475bcff385767e5)

rust-timer · 2025-09-20T13:39:53Z

Finished benchmarking commit (09a6b1d): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@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
Improvements ✅ (primary)	-0.3%	[-0.3%, -0.2%]	3
Improvements ✅ (secondary)	-1.5%	[-9.2%, -0.3%]	11
All ❌✅ (primary)	-0.3%	[-0.3%, -0.2%]	3

Max RSS (memory usage)

Results (primary 0.9%, secondary 3.4%)

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

	mean	range	count
Regressions ❌ (primary)	1.8%	[0.8%, 2.4%]	3
Regressions ❌ (secondary)	3.4%	[3.4%, 3.4%]	1
Improvements ✅ (primary)	-1.7%	[-1.7%, -1.7%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.9%	[-1.7%, 2.4%]	4

Cycles

Results (secondary -2.5%)

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

Binary size

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

Bootstrap: 472.018s -> 473.009s (0.21%)
Artifact size: 389.98 MiB -> 389.96 MiB (-0.00%)

… all? This demonstrates the theoretical limits of optimizing the quoting process.

rustbot · 2025-09-22T03:58:17Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

Zalathar · 2025-09-22T04:00:28Z

@bors try @rust-timer queue

(EXPERIMENT) Perf experiments for target-machine command-line quoting

rust-bors · 2025-09-22T06:13:26Z

☀️ Try build successful (CI)
Build commit: 3cad4c1 (3cad4c1f7f06414cb89aa67750ddd77153f59100, parent: 9f32ccf35fb877270bc44a86a126440f04d676d0)

rust-timer · 2025-09-22T07:23:36Z

Finished benchmarking commit (3cad4c1): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@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%]	2
Improvements ✅ (primary)	-0.4%	[-0.5%, -0.3%]	5
Improvements ✅ (secondary)	-1.5%	[-18.4%, -0.0%]	22
All ❌✅ (primary)	-0.4%	[-0.5%, -0.3%]	5

Max RSS (memory usage)

Results (primary 0.9%, secondary 2.4%)

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

	mean	range	count
Regressions ❌ (primary)	2.5%	[2.4%, 2.5%]	2
Regressions ❌ (secondary)	4.5%	[2.3%, 5.1%]	8
Improvements ✅ (primary)	-0.6%	[-0.8%, -0.5%]	2
Improvements ✅ (secondary)	-1.9%	[-2.3%, -1.0%]	4
All ❌✅ (primary)	0.9%	[-0.8%, 2.5%]	4

Cycles

Results (primary 2.0%, secondary -1.9%)

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

	mean	range	count
Regressions ❌ (primary)	2.0%	[2.0%, 2.0%]	1
Regressions ❌ (secondary)	2.4%	[2.2%, 2.5%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.6%	[-5.5%, -2.2%]	5
All ❌✅ (primary)	2.0%	[2.0%, 2.0%]	1

Binary size

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

Bootstrap: 471.273s -> 471.264s (-0.00%)
Artifact size: 387.92 MiB -> 389.96 MiB (0.53%)

bors · 2025-09-22T16:01:50Z

☔ The latest upstream changes (presumably #146879) made this pull request unmergeable. Please resolve the merge conflicts.

Remove current code for embedding command-line args in PDB The compiler currently has code that will obtain a list of quoted command-line arguments, and pass it through to TargetMachine creation, so that the command-line args can be embedded in PDB output. This PR removes that code, due to subtle concerns that might not have been apparent when it was originally added. --- Those concerns include: - The entire command-line quoting process is repeated every time a target-machine-factory is created. In incremental builds this typically occurs 500+ times, instead of happening only once. The repeated quoting constitutes a large chunk of instructions executed in the `large-workspace` benchmark. - See #146804 (comment) for an example of the perf consequences of skipping all that work. - This overhead occurs even when building for targets or configurations that don't emit PDB output. - Command-line arguments are obtained in a way that completely bypasses the query system, which is a problem for the integrity of incremental compilation. - Fixing this alone is likely to inhibit incremental rebuilds for most or all CGUs, even in builds that don't emit PDB output. - Command-line arguments and the executable path are obtained in a way that completely bypasses the compiler's path-remapping system, which is a reproducibility hazard. - #128842 --- Relevant PRs: - #113492 - #130446 - #131805 - #146700 - #146973 Zulip thread: - https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Some.20PDB.20info.20bypasses.20the.20query.20system.20and.20path.20remapping/with/541432211 --- According to #96475, one of the big motivations for embedding the command-line arguments was to enable tools like Live++. [It appears that Live++ doesn't actually support Rust yet](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/embeded.20compiler.20args.20and.20--remap-path-prefix/near/523800010), so it's possible that there aren't any existing workflows for this removal to break. In the future, there could be a case for reintroducing some or all of this functionality, guarded behind an opt-in flag so that it doesn't cause problems for other users. But as it stands, the current implementation puts a disproportionate burden on other users and on compiler maintainers.

Remove current code for embedding command-line args in PDB The compiler currently has code that will obtain a list of quoted command-line arguments, and pass it through to TargetMachine creation, so that the command-line args can be embedded in PDB output. This PR removes that code, due to subtle concerns that might not have been apparent when it was originally added. --- Those concerns include: - The entire command-line quoting process is repeated every time a target-machine-factory is created. In incremental builds this typically occurs 500+ times, instead of happening only once. The repeated quoting constitutes a large chunk of instructions executed in the `large-workspace` benchmark. - See rust-lang/rust#146804 (comment) for an example of the perf consequences of skipping all that work. - This overhead occurs even when building for targets or configurations that don't emit PDB output. - Command-line arguments are obtained in a way that completely bypasses the query system, which is a problem for the integrity of incremental compilation. - Fixing this alone is likely to inhibit incremental rebuilds for most or all CGUs, even in builds that don't emit PDB output. - Command-line arguments and the executable path are obtained in a way that completely bypasses the compiler's path-remapping system, which is a reproducibility hazard. - rust-lang/rust#128842 --- Relevant PRs: - rust-lang/rust#113492 - rust-lang/rust#130446 - rust-lang/rust#131805 - rust-lang/rust#146700 - rust-lang/rust#146973 Zulip thread: - https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Some.20PDB.20info.20bypasses.20the.20query.20system.20and.20path.20remapping/with/541432211 --- According to rust-lang/rust#96475, one of the big motivations for embedding the command-line arguments was to enable tools like Live++. [It appears that Live++ doesn't actually support Rust yet](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/embeded.20compiler.20args.20and.20--remap-path-prefix/near/523800010), so it's possible that there aren't any existing workflows for this removal to break. In the future, there could be a case for reintroducing some or all of this functionality, guarded behind an opt-in flag so that it doesn't cause problems for other users. But as it stands, the current implementation puts a disproportionate burden on other users and on compiler maintainers.

Zalathar added the S-experimental Status: Ongoing experiment that does not require reviewing and won't be merged in its current state. label Sep 20, 2025

Zalathar removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 20, 2025