measureme VS cargo-bisect-rustc

To dig further into one specific rustc process called by Cargo, cargo +nightly rustc -- -Z self-profile -p some_crate https://github.com/rust-lang/measureme/blob/master/summarize/README.md

> When does the Rust compiler spend most of it's time? Is it at the checking stage?

rustc has a self-profiler that can be used to answer this question [0], as well as a mode that times each compiler pass [1].

There's no single reason the Rust compiler is slow, as it depends quite heavily on the code being compiled. For some codebases, LLVM code takes up most of the time; in other codebases (e.g., extremely generic-heavy codebases), it'll be checking-related passes.

[0]: https://github.com/rust-lang/measureme/blob/master/summarize...

[1]: https://wiki.alopex.li/WhereRustcSpendsItsTime

> One big downside is losing the ability to build any commit from source without meta-complexity creeping in. For example, let’s say that you are trying to do git bisect. At some point, git checks out an older commit, but the script fails to build from source because the binary that is being used to build the compiler is now the wrong version. Sure, this can be addressed, but this introduces unwanted complexity that contributors would rather not deal with.

If it's the main concern of using a prior build of the compiler, an alternative solution is to develop a tool for contributors to automate and ease the process. For example, Rust has this: https://github.com/rust-lang/cargo-bisect-rustc

Added support for tools like cargo-bisect-rustc.

Finally, https://github.com/rust-lang/cargo-bisect-rustc/blob/master/TUTORIAL.md can bisect Nightlies or (if recent enough, I think CI artifacts are kept 3 months) PRs to tell you one introduced a problem.