Timing report of `cargo build --timings` fails to register dependency resolution timings

[MMeent]

Problem

When I run cargo build --timings on a newly checked-out branch, it automatically tries to update the crates.io indexes and download the dependencies, but the timing of this is not included in the graph. On a slow network, this can take a long time.

As it is the first item that is executed, this can lead to extremely large gaps in the timings data where according to the graphs, nothing is happening, but where we're actually downloading the latest dependencies.

Proposed Solution

It would be super useful if the report included, amongst others:

• The time it takes to update the crates.io index
• For each crate that we download a new version of, the time it took to download this crate.

Notes

No response

[weihanglo]

Personal thoughts:

• Download timing reflects only one's local network, and might not be as meaningful as “build” timing report.
• Downloading crates is usually a one-shot task. People typically won't delete cache .crate file and say “Oh, I need to test my network condition. Let me cargo b --timings.” What they often do is to cache those data and make it --offline or else.
• From the implementation perspective, it might be a bit messy to maintain a timing data throughout out the entire operation. As of now, it nicely fits in a single module and exposes a minimal interface to interact with.
• Should cargo fetch get a --timings flag as well? What about cargo generate-lockfile? It seems a bit weird though. Maybe we could have a separate report of download timing report.

Some alternative solutions:

• Have a line reporting how long it takes to update registry index.
• Track time spent of download .crate for each crate and report it when in --verbose mode. Cargo already reports total download time spent, such as

  Downloaded 275 crates (59.6 MB) in 8.28s (largest was `windows` at 11.5 MB)

In general, I don't feel like it makes sense to have a single report for both build timing and download timing. That said, Cargo could still track time spent over network in a separate report.

[epage]

Another way of resolving this is if we use tracing, we could offer an unstable flag for dumping the traces (like with tracing-chrome) which would allow us a way to capture timing about the whole lifetime of the process (e.g. I want to capture Cargo.toml parsing and resolving) without having to manually track all of the data.

Maybe we'd even be able to capture the information ourselves and include it in the timings report.