improve `proxy_mode` (e.g. rustc wrapper) startup time?

[matthiaskrgr]

time ~/.rustup/toolchains/master/bin/rustc >& /dev/null
0,040 total

time ~/.cargo/bin/rustc >& /dev/null
0,272 total

That's almost 7x slower.
I wonder if there is some something we can do to get these numbers a bit closer?

[jyn514]

@matthiaskrgr this is about the rustup wrapper, not the x.py rustc shim, right? If so I think this should be moved to https://github.com/rust-lang/rustup/.

[matthiaskrgr]

Ah, ~/.cargo/bin/rustc is rustup? Yes, the issue should be moved then. :)

[kinnison]

I can confirm that the difference in performance is around 6x:

listless% hyperfine ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc rustc 
Benchmark #1: /home/dsilvers/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc
  Time (mean ± σ):      11.3 ms ±   0.9 ms    [User: 6.9 ms, System: 4.3 ms]
  Range (min … max):    10.1 ms …  15.4 ms    252 runs
 
Benchmark #2: rustc
  Time (mean ± σ):      71.2 ms ±   2.3 ms    [User: 60.0 ms, System: 11.2 ms]
  Range (min … max):    67.3 ms …  76.2 ms    41 runs
 
Summary
  '/home/dsilvers/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc' ran
    6.31 ± 0.54 times faster than 'rustc'
listless%                                                                                

[kinnison]

Looking locally, ca. 15ms are before main() is entered (presumably due to dynamic link time for all the libraries rustup uses by dint of being linked to curl).

It looks like about 25ms is taken parsing manifest files, sadly this is also done twice, and thus accounts for the vast majority of the extra time. The toml parser must be quite inefficient.

It might be possible to knock one of those parse steps on the head since in theory we only need to parse once, but it'll involve quite a bit of refactoring.

If someone wants to begin to look at this, then the place to start is the config.rs file, around line 620 which is find_or_install_override_toolchain_or_default(). In the sub-function components_exist() you can see it acquire the manifest (since it needs it) and then it lists the components in order to check that everything needed is installed. The list_components() function though ends up loading the manifest itself. Perhaps the distributable toolchain could cache the manifest having loaded it?

[rbtcollins]

To help triage this, how much does this contribute to typical build times? like, - sure we can put a chunk of time into making this snappy, and that would be good, but if a typical build is 1500ms ... ?

[jyn514]

@rbtcollins I wouldn't notice so much on builds, but this hurts things like rustc --explain E0111 or rustc --help.

$ time /home/joshua/.local/lib/rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc --help >/dev/null
real	0m0.050s
user	0m0.026s
sys	0m0.020s
$ time rustc --help >/dev/null
real	0m0.157s
user	0m0.129s
sys	0m0.028s
$ time pip --help >/dev/null
real	0m0.206s
user	0m0.178s
sys	0m0.028s
$ time go help >/dev/null
real	0m0.022s
user	0m0.008s
sys	0m0.017s

[matthiaskrgr]

to addd to the list:

time clang >&/dev/null 
clang >&/dev/null  0,04s user 0,03s system 96% cpu 0,064 total

time gcc >& /dev/null
gcc >&/dev/null  0,00s user 0,01s system 86% cpu 0,009 total

[kinnison]

@matthiaskrgr

Comparing with C compilers is disingenuous since the number of rustc invocations for a similarly sized codebase will be many fewer. For example, rustup is around 130 .rs files, but including its dependencies the total rustc invocations is only 320 or so. If we assume a wasted 35ms (the repeated manifest parse) of CPU time on my computer per rustc invocation and we generously assume that all that waste is reflected in the wallclock compile time at the same parallelism that the build occurs at, then of the 83s it took my computer to build rustup just now at 6.1x parallel, then that's 11375ms wasted which at 6.1x parallel is 1.864s of wallclock time or 2.2% of all build time in a debug build.

The same maths on a release build, 11375ms wasted for a total build time of 195s is only 0.95% of the total runtime of the build.

@jyn514

Considering the rustc --explain or rustc --help scenarios is also disingenuous. Most humans don't need to run those repeatedly in tight loops, and will take far longer than the wasted 50ms or so even noticing the screen updated let alone reading and grokking the output.

however

Having said all that, I do think it's worth correcting the double-load of the manifest since it's wasteful to do that anyway, and that shouldn't be too complex to do in a grungy way; or only medium hard to do nicely.

What would be of even more use though is working out how it takes 35ms on a 4GHz CPU core to parse the manifest, that's utterly abysmal.

[kinnison]

Further investigation yields:

The majority of the time spent parsing the manifest is in the toml load itself, i.e. before we apply any semantic understanding to the manifest. The channel is around 700k and will only get larger over time. Another possible improvement to do would be to trim out anything not relevant to the toolchain being installed when fetching the manifest. That ought not to be too complex to do and would speed up future operations since the manifest would be significantly smaller

[kinnison]

I wrote a simple trimmer for the manifests to reduce the toml quantity in installed toolchains. Doing that results in the following (stable is untrimmed, beta is trimmed):

listless% echo stable > rust-toolchain                                        
listless% hyperfine rustc                                                     
Benchmark #1: rustc
  Time (mean ± σ):      69.8 ms ±   1.9 ms    [User: 59.5 ms, System: 10.2 ms]
  Range (min … max):    67.4 ms …  76.1 ms    42 runs
 
listless% echo beta > rust-toolchain                                          
listless% hyperfine rustc                                                    
Benchmark #1: rustc
  Time (mean ± σ):      19.6 ms ±   0.7 ms    [User: 14.2 ms, System: 5.4 ms]
  Range (min … max):    18.7 ms …  22.9 ms    128 runs
 
listless%                                                                    

(for reference, directly invoking rustc (stable or beta) without rustup in the way is ca. 11ms.