CPU usage regression for ripgrep

[sophiajt]

As reported on Twitter: https://twitter.com/jleedev/status/964324747277455360

Looks like ripgrep with 1.24 consumes far more cpu power to compile than it did with 1.23.

[matthiaskrgr]

Is there a way to run RUSTFLAGS="-Z time-llvm-passes -Z time-passes" on stable/beta to get some background data on this issue?

[pietroalbini]

@matthiaskrgr the RUSTC_BOOTSTRAP=1 environment variable should do the trick.

[matthiaskrgr]

Looks like it's the codegen-units that make the difference here. (note: this system has a i5-7200U dual core / 4 threads cpu).
The tweet suggests that the machine could be an RPI, how many cores do these things usually have?

RUSTC_BOOTSTRAP=1 RUSTFLAGS="-Z time-passes -C codegen-units=1"  cargo +1.23.0  build --release
real	1m31,136s
user	3m5,831s
sys	0m3,018s

RUSTC_BOOTSTRAP=1 RUSTFLAGS="-Z time-passes "  cargo +1.23.0  build --release
real	1m29,970s
user	3m1,953s
sys	0m2,963s

RUSTC_BOOTSTRAP=1 RUSTFLAGS="-Z time-passes -C codegen-units=1" cargo +stable  build --release 

real	1m27,657s
user	2m57,814s
sys	0m3,034s

RUSTC_BOOTSTRAP=1 RUSTFLAGS="-Z time-passes" cargo +stable  build --release 

real	1m34,053s
user	5m35,334s
sys	0m4,888s

[ishitatsuyuki]

Parallel codegen-units is not as efficient as the old serial approach, and is likely the cause.

[nikomatsakis]

Added to #47745

[nikomatsakis]

My bad, this a compile-time regression?

[nikomatsakis]

triage: P-medium

There doesn't seem to be a lot to do here, other than perhaps reconsidering our defaults?

cc @alexcrichton -- what is the current strategy for --release, anyway? (How many CGU etc?)