Improve startup time of bootstrap

[clubby789]

If the user has a build/host symlink set up, we can determine the target triple by reading it rather than invoking rustc. This significantly reduces startup time of bootstrap once any kind of build has been done
New approach explained below

➜  hyperfine -p 'git checkout -q master' -N './x.py -h' -r 50
Benchmark 1: ./x.py -h
  Time (mean ± σ):     140.7 ms ±   2.6 ms    [User: 99.9 ms, System: 39.3 ms]
  Range (min … max):   136.8 ms … 149.6 ms    50 runs
 
➜  rust git:(master) hyperfine -p 'git checkout -q speedup-bootstrap-py' -N './x.py -h' -r 50
Benchmark 1: ./x.py -h
  Time (mean ± σ):      95.2 ms ±   1.5 ms    [User: 67.7 ms, System: 26.7 ms]
  Range (min … max):    92.9 ms …  99.6 ms    50 runs

Also a small microoptimisation in using string splitting rather than regex when reading toml, which saves a few more milliseconds (2-5 testing locally), but less important.

Profiling shows the remaining runtime is around half setting up the Python runtime, and the vast majority of the remaining time is spent in subprocess building and running bootstrap itself, so probably can't be improved much further.

[rustbot]

r? @ozkanonur

(rustbot has picked a reviewer for you, use r? to override)

[onur-ozkan]

Thank you for the enhancement, looks great:) Only one non-blocker suggestion

--

r=me once the CI is green

[onur-ozkan]

@bors rollup=iffy

[clubby789]

@bors r=ozkanonur

[bors]

📌 Commit 4249728f3eca3efb59264dfaf7ce1852080c0f69 has been approved by ozkanonur

It is now in the queue for this repository.

[bors]

⌛ Testing commit 4249728f3eca3efb59264dfaf7ce1852080c0f69 with merge 7d63b30bd1d9ca39bdcb71fd21a85697be41e588...

[bors]

💔 Test failed - checks-actions

[clubby789]

Looks like the triple should be x86_64-unknown-gnu, but the symlink is i686-unknown-linux-gnu. I'll look into it
@rustbot author

rust/src/bootstrap/lib.rs

Lines 503 to 517 in eda41ad

	let build_triple = build.out.join(&build.build.triple);
	t!(fs::create_dir_all(&build_triple));
	let host = build.out.join("host");
	if host.is_symlink() {
	// Left over from a previous build; overwrite it.
	// This matters if `build.build` has changed between invocations.
	#[cfg(windows)]
	t!(fs::remove_dir(&host));
	#[cfg(not(windows))]
	t!(fs::remove_file(&host));
	}
	t!(
	symlink_dir(&build.config, &build_triple, &host),
	format!("symlink_dir({} => {}) failed", host.display(), build_triple.display())
	);

'host' seems to refer to the build triple, rather than the actual host triple

[clubby789]

Save a few cycles time by lifting all the uname invocations to a single command

[clubby789]

@bors r=jyn514

[bors]

📌 Commit 33fe42bcc5fe42af90ccbd3286f94f0153689ee0 has been approved by jyn514

It is now in the queue for this repository.

[bors]

⌛ Testing commit 33fe42bcc5fe42af90ccbd3286f94f0153689ee0 with merge 3aa56dfe33d61d57f8852cf9f6d6617aca6489a0...

[bors]

💔 Test failed - checks-actions

[clubby789]

Ah - I'll revert the uname changes then :/
I think I'll actually just move the -o one out to where it's needed

[jyn514]

@bors r+ rollup=iffy

[bors]

📌 Commit 9a86ceb has been approved by jyn514

It is now in the queue for this repository.

[bors]

⌛ Testing commit 9a86ceb with merge 917b0b6...

[bors]

☀️ Test successful - checks-actions
Approved by: jyn514
Pushing 917b0b6 to master...

[rust-timer]

Finished benchmarking commit (917b0b6): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

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

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: 644.999s -> 643.928s (-0.17%)

[MabezDev]

This PR seems to have broken the configure utility on my machine.

./configure --experimental-targets=Xtensa --release-channel=nightly --enable-extended --tools=clippy,cargo,rustfmt --enable-lld
configure: processing command line
configure: 
configure: build.configure-args := ['--experimental-targets=Xtensa', '--release-c ...
configure: llvm.experimental-targets := Xtensa
configure: rust.channel         := nightly
configure: build.extended       := True
Traceback (most recent call last):
  File "/home/mabez/development/rust/xtensa/rust-xtensa-dev/./src/bootstrap/configure.py", line 548, in <module>
    section_order, sections, targets = parse_args(sys.argv[1:])
                                       ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/mabez/development/rust/xtensa/rust-xtensa-dev/./src/bootstrap/configure.py", line 277, in parse_args
    apply_args(known_args, option_checking, config)
  File "/home/mabez/development/rust/xtensa/rust-xtensa-dev/./src/bootstrap/configure.py", line 339, in apply_args
    build_triple = build(known_args)
                   ^^^^^^^^^^^^^^^^^
  File "/home/mabez/development/rust/xtensa/rust-xtensa-dev/./src/bootstrap/configure.py", line 284, in build
    return bootstrap.default_build_triple(verbose=False)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/mabez/development/rust/xtensa/rust-xtensa-dev/src/bootstrap/bootstrap.py", line 259, in default_build_triple
    kernel, cputype, processor = uname.decode(default_encoding).split()
    ^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: too many values to unpack (expected 3)

The offending line is https://github.com/rust-lang/rust/pull/111562/files#diff-9e25a089f077eae8c8cefe9586cc07498e64cd950be4c954cb90e4245e5f9fc3R259. On my machine the output of uname -smp is Linux x86_64 AMD Ryzen 7 3800XT 8-Core Processor which would be split into more than 3 items.