Hi there! I wrote a tool to visualize cargo build plans as Gantt charts. Support for build plan output landed as an unstable option in cargo nightly within the last month. I don't think Gantt charts are the perfect visualization here, but they're better than any other option I've come up with so far. Note that the timing information in the chart is fictional--build actions are assigned a start time purely based on their dependency chain, and all actions are given a "1 second" duration. Also note that cargo build plans are by definition target-specific--they represent the exact set of actions that cargo would run for a specific build.
Why not just a DAG and leave off the time intervals? Unless the compiler can provide some sort of cost estimates per node of the plan and/or feedback during build so you can adjust the times to reflect reality as it goes, then, using the Gantt format probably isn't useful.
EDIT: Alternatively, use Cost Factors for the nodes that reflects average relative times gathered for the compiler. For example:
Compilation to AST : CF 1
AST -> MIR : CF 2
Borrow Checking : CF 1.25
MIR Optimization : CF 2.25
LLIR Generation : CF 0.75
LLVM Compilation : CF 3.5
LLVM Optimization : CF 5.0
LLVM Linking : CF 1.5
Then, make the Gantt nodes time lengths reflect these relative factors.
I tried that first! I wrote a Python script to generate GraphViz dot format and the output was unreadable. I agree that a Gantt chart is not the optimal format here but it's substantially more readable and gets the gist of the information across.
Also note that not every step in a build plan is compilation--it also includes running build scripts, so getting those estimates right would be hard. It would be a nice addition to be able to get timing information out of cargo and reuse this visualization with actual timing from a build.
Perhaps you could just provide defaults of 1.0 for all steps as a Cost Factor with a configuration file for setting the CF of each type of node (not for a specific plan, but, in general). Then, later, you could possibly use the actual timings of builds over time to automagically adjust the configuration file. Interesting to think about if nothing else.
OK, I got motivated enough to hack cargo to produce profiling output in Chrome's trace_event format (viewable in chrome://tracing in Chrome) and I wrote a Python script to merge that output into a build plan, and then changed the build plan graphing code to use those timings when available.
