Tracking Issue for JSON timings

[ehuss]

Summary

Original issue: #7405
Implementation: #7311
Documentation: N/A

--timings=json is an unstable option which emits some JSON information about the build timings. It outputs one JSON object per rustc invocation defined in TimingInfo.

Unresolved Issues

• Unclear if this is the right design or is useful. This was added experimentally without any real intent to use it. The concept was based on rustc's build system, which emits timing information using text. The idea was to provide something similar so that users can track their build times on a fine-grained basis. However, I think we are unlikely to use it in rustc in the foreseeable future.
• Integration of compiler timing data and/or -Zself-profile Add --json=timings option to print build timings compiler-team#873
• The interaction with Cargo's --message-format. Should we control the output with a unified flag or have a separate --timings flag. See Tracking Issue for JSON output format of cargo package --list #15353 for a similar discussion of cargo package --list.
• Should the format be versioned?

Future Extensions

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

[repi]

we would love to have this to be able to build tools that diff build times our large Rust workspaces, both between ordinary code changes in PRs for the workspace as well as for dependency changes and rust upgrades.

That said, we haven't tested yet with the existing unstable support, but it does look like it is missing a lot of functionality that is in the HTML output, such as frontend/backend time split for each build, start time of build etc. Would like to have enough info in the JSON output to be able to recreate the output one currently have in the HTML

[smklein]

This would be a great feature for automated tools to track differences between build speeds.

cargo build --timings, and the corresponding HTML report, are great for consumption by human eyeballs, but are a little rougher for machines to compare. cargo build --timings=json seems like a great tool, to, for example, "compare the time it takes to build a set of many packages in a workspace across all commits to a repo".