Skip to content

Add a debug option to generate a flamegraph for compiler performance #4075

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
carolynzech opened this issue May 14, 2025 · 2 comments
Open
Labels
[C] Internal Tracks some internal work. I.e.: Users should not be affected. [E] Performance Track performance improvement (Time / Memory / CPU)

Comments

@carolynzech
Copy link
Contributor

Proposed change: For a given code generation pass, we'd get the call tree annotated with the time spent in each function. For instance, if codegen_items calls codegen_function, which calls codegen_statement n times, etc., we'd get the time we spent in each of those calls, down to the end of the call tree. I'm imagining we'd visualize it as a tree because the depth of the call stack is also important, but I'm flexible on the format; the main point is getting data on how long different parts of codegen take, not just codegen as a whole.

Motivation: From some rudimentary benchmarking with with_timer:

/// Execute the provided function and measure the clock time it took for its execution.
/// Log the time with the given description.
pub fn with_timer<T, F>(func: F, description: &str) -> T

we've determined that most of Kani's compiler runtime comes from code generation. But we need more fine-grained data to know why code generation is slow. Currently, it's unclear whether:

  • Most functions are fast enough, but there are specific outliers we can blame, e.g., if codegening a function with fat pointers or dynamic dispatch is much slower than codegening functions without, or
  • Most functions are fast enough in isolation, but we have a deep call tree so their cumulative time is slow, suggesting that we need a larger-scale refactoring to produce speedups, or at least small-scale optimizations of multiple functions.

Having this data would help us make that determination.

@carolynzech carolynzech added [E] Performance Track performance improvement (Time / Memory / CPU) [C] Internal Tracks some internal work. I.e.: Users should not be affected. labels May 14, 2025
@tautschnig
Copy link
Member

I previously used flamegraphs for such profiling, and the Rust profiling docs link to https://github.com/flamegraph-rs/flamegraph - would that perhaps be a good option?

@carolynzech
Copy link
Contributor Author

I previously used flamegraphs for such profiling, and the Rust profiling docs link to https://github.com/flamegraph-rs/flamegraph - would that perhaps be a good option?

Yep, that looks great!

@carolynzech carolynzech changed the title Add a debug option to measure fine-grained compiler performance Add a debug option to generate a flamegraph for compiler performance May 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[C] Internal Tracks some internal work. I.e.: Users should not be affected. [E] Performance Track performance improvement (Time / Memory / CPU)
Projects
None yet
Development

No branches or pull requests

2 participants