Introduce -Zmacro-stats
#142069
Introduce -Zmacro-stats
#142069
Conversation
They will be used in a subsequent commit.
It currently only inserts separators into `usize`s, because that's all that has been needed so far. `-Zmacro-stats` will need `isize` and `f64` handling, so this commit adds that.
rustbot
added
S-waiting-on-review
|
I used this recently on a non-open-source codebase with ~100,000 lines of Rust code. |
|
|
|
This sounds awesome! @lqd recently let me know about the fact that |
I hadn't heard about that... |
|
FWIW I tried to use it, and it gives me the durations of proc macro executions for individual macros (e.g. |
|
builtin derives are not proc-macros, but you're more than welcome to add their expansion to the self-profiler :) code-size is an interesting metric but it's not always correlated with compile times which you're interested in optimizing: you still want expansion times (example: cranelift-codegen has two huge functions of the same size, one of which takes 8ms in dataflow, the other 2.5s) |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Right, that was my first question on this PR, if we can just add it to
It's a very rough approximation, of course. Ideally, I would like to see "this macro generated code that took the compiler 2.5s to typecheck", but I don't suppose that's really feasible easily today, so I'll take what I can get :) |
|
AFAIK there's nothing inherent to the data model that would prevent adding information to correlate between events of different queries, if that's what was needed for nick's project or your query (e.g. if compilation time was not in expansion but elsewhere). But this is getting offtopic so I'll stop here. |
| Ty(P<ast::Ty>) { "type"; one fn visit_ty; fn visit_ty; fn make_ty; } | ||
| Expr(P<ast::Expr>) { | ||
| "expression"; | ||
| one fn visit_expr; fn visit_expr; fn pprust::expr_to_string; |
There was a problem hiding this comment.
| one fn visit_expr; fn visit_expr; fn pprust::expr_to_string; | |
| one fn visit_expr; fn visit_expr; pprust::expr_to_string; |
fn is used because this macro generates definitions for all these functions and it's convenient if the definitions can be found by searching for fn foo, but this macro doesn't define pprust::expr_to_string.
Style nit: thus it would look better on the same line with "expression";.
There was a problem hiding this comment.
fn is used because this macro generates definitions for all these functions
No, it doesn't, it just calls them. We could get rid of all the fns, they aren't necessary.
As for the position, I put these three on the same line because they're the three that get grouped with the one or the many.
There was a problem hiding this comment.
Yeah, if there are no definitions then the other fns can also be removed.
|
|
||
| // This code is useful for debugging `-Zmacro-stats`. For every | ||
| // invocation it prints the full input and output. | ||
| if false { |
There was a problem hiding this comment.
Todo: not forget to remove this.
There was a problem hiding this comment.
I'd like to keep it. I used it a lot while writing and testing this PR, and there's a good chance it'll be needed in the future. I don't want to have to recreate it.
petrochenkov
added
S-waiting-on-author
It collects data about macro expansions and prints them in a table after expansion finishes. It's very useful for detecting macro bloat, especially for proc macros. Details: - It measures code snippets by pretty-printing them and then measuring lines and bytes. This required a bunch of additional pretty-printing plumbing, in `rustc_ast_pretty` and `rustc_expand`. - The measurement is done in `MacroExpander::expand_invoc`. - The measurements are stored in `ExtCtxt::macro_stats`.
Introduce
-Zmacro-stats.It collects data about macro expansions and prints them in a table after expansion finishes. It's very useful for detecting macro bloat, especially for proc macros.
r? @petrochenkov