Add actionable suggestions to timings output

Problem

The timings argument stabilised in 1.60 is accompanied by documentation with some tips for addressing build times. https://doc.rust-lang.org/nightly/cargo/reference/timings.html

Those Tips are:

Hard to discover
Not contextualised to the build I just ran
Hard to action for programmers less experienced with compiled languages. They need to identify which tips are relevant to which crates.

I want to suggest we use cargo to make those tips into workspace-specific actionable suggestions thus empowering people with less experience to optimise their build times.

Proposed Solution

I think the following suggestions listed in the cargo reference doc are converted into actionable suggestions informed by the stats collected by cargo:

Split large crates into smaller pieces.

We can identify a large crate internal to the workspace by calculating the % of build times higher than some threshold.

You can add an actionable diagnostic to the html and json report like the following:

Crate X takes 57% of total build time. Can you break it up into several smaller crates?

Look for a crate being built multiple times with different versions. Try to remove the older versions from the dependency graph.

Collect all packages built in the DAG into a HashMap<Package, Vec<CrateVersion>>, sort the HashMap by the length of the vector of versions and generate suggestions for top K packages along the lines

Crate X is built with K versions - $LIST_OF_VERSIONS - and they all take Y% of total build time. run cargo tree to find where they come from and see if you can use fewer versions in your build.

Look for slow dependencies. Check if they have features that you may wish to consider disabling.

For the crates that are slowest to compile, list all the features used and suggest turning some of them off.

Crate X is built with features: $LIST_OF_FEATURES. Try turning some of those features off.

Additional tips not in the reference

Linking the executable takes a long time

If we identify that the step that links binary crates takes longer than some threshold time, we can suggest other linkers (arch-dependant)

Linking the executable with $LINKER takes Y% of build time, try using mold/llvm.lld instead of the default linker

Notes

as part of testing this feature, the suggestions should be implemented to verify they actually improve build times.
Calculating suggestions requires some heuristics-based values that might be too machine-dependent

I would be happy to create a prototype PR even if the feature is considered too big to land given the current maintainer time constraints.

rust-lang / cargo