measureme: Provide a tool to see what user code is causing rustc to use lots of time
We should have a way to calculate how long each item in your codebase takes to compile. Conceptually this would work by grouping the measureme data by DefId/NodeId or some other identifier rather than by the query name. We can then output a sorted list of items by how long each takes.
For example, the output might look like this:
$ summarize code-profile /path/to/rustc-results
Total time in rustc: 120 seconds
----------------------------------------
| % time | Item |
| ------ | -----------------------------
| 20.4% | example::foo::bar::clone() |
| 10.2% | example::baz::widget::bla() |
(more rows)
This will require changes to the profiling code in rustc to record DefIds or NodeIds for each query.
About this issue
- Original URL
- State: open
- Created 5 years ago
- Reactions: 39
- Comments: 15 (10 by maintainers)
Actually one thing that I think would be really cool is to have a diagram like this…
for LLVM IR. The first ring around the center could be crate, and then each layer deeper could be a module, eventually getting to individual functions. I feel like that alone would be very informative to just say “oh wow serde is 90% of my crate?!” and going from there.
Now it’s true though that the amount of LLVM code is only a proxy for the number we care about, compile time, so it’s not perfect.
have made an POC with adding the clang time-trace feature in the self-profiling but do not know if it is something that can be up streamed can find the code here https://github.com/andjo403/rust/tree/llvmProfiler
I recently was told about cargo-llvm-lines. It tells you how many lines of LLVM IR is produced for each function/method, and how many times each function/method is instantiated. (The latter number can get surprisingly high for generic functions/methods.)
It’s great. I’ve already used it for https://github.com/rust-lang/rust/pull/72013, https://github.com/rust-lang/rust/pull/72166, and https://github.com/rust-lang/rust/pull/72139. Although the number of lines of LLVM IR code is only a proxy for the time taken to compile the code, it’s good enough in practice to give useful results. As Alex said above, rough information is much better than no information.
Sunbursts have the disadvantage that your eye sees the area of a section, but the angle is what actually matters, so sections at outside look bigger than sections near the center. I prefer flamegraphs.
+1