Skip to content
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

Support high water mark temporal flame graphs #326

Merged
merged 4 commits into from
Jun 9, 2023

Conversation

godlygeek
Copy link
Contributor

Building on top of the work to support our temporal flame graphs for analyzing memory leaked within a user-selected range, allow creating temporal flame graphs for analyzing the high water mark within a user-selected range.

@godlygeek
Copy link
Contributor Author

@pablogsal I'd appreciate it if you could skim through this sometime soon and share your initial impressions. I'm a bit worried that you'll be unhappy with how complex TemporalHighWaterMarkAggregator needs to be, so I'd welcome any suggestions for how to simplify it.

But hey, at least this one's only about 1000 lines!

@pablogsal
Copy link
Member

pablogsal commented Mar 9, 2023

But hey, at least this one's only about 1000 lines!

Screenshot 2023-03-09 at 14 36 23

Aha 🤔

@pablogsal
Copy link
Member

image

@godlygeek
Copy link
Contributor Author

More than 400 LoC out of that are new tests ☹️

Let's make some time to chat about what to do with this. I'd rather not release temporal leaks without also releasing temporal high water mark reporting... And given #382 we probably should cut a release soon. I'm tempted to back out the temporal leaks stuff (at least the CLI entry point for it and any docs) until we're comfortable landing this.

I'm gonna rebase this, and also take another pass and see if I can find any ways to simplify it.

@pablogsal
Copy link
Member

@godlygeek You can rebase this now :)

@godlygeek
Copy link
Contributor Author

Done. I'm still tweaking this a bit, so I'm going to leave it as draft, but I'd love it if you could take another look at the first commit, in particular, and see if there's anything that stands out to you as wrong or bad or difficult to understand.

I think I need to add more comments, and maybe some diagrams, but the implementation should remain basically unchanged

Copy link
Member

@pablogsal pablogsal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am pushing a commit to simplify the creation of these structs using brace initializers.

size_t last_snapshot_peak = highest_peak_by_snapshot.at(history.last_known_snapshot);
history.rebase(last_snapshot_peak);

HistoricalContribution hc;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not using the brace-constructor here?

hc.contrib.allocations = history.allocations_contributed_to_last_known_peak;
hc.contrib.bytes = history.bytes_contributed_to_last_known_peak;

bool skip;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's rename this to skip_last_contribution or something similar so is clear what we are skipping

Comment on lines 452 to 456
HistoricalContribution hc;
hc.as_of_snapshot = final.last_known_snapshot;
hc.peak_index = current_peak;
hc.contrib = hwm;
ret.push_back(hc);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can create the element in-pace using emplace_back no?

Comment on lines 443 to 445
Contribution hwm;
hwm.allocations = final.allocations_contributed_to_last_known_peak;
hwm.bytes = final.bytes_contributed_to_last_known_peak;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not brace-constructor?

Comment on lines 460 to 464
HistoricalContribution hc;
hc.as_of_snapshot = final.last_known_snapshot + 1;
hc.peak_index = -1;
hc.contrib = leaks;
ret.push_back(hc);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as before: We can create the element in-pace using emplace_back

@codecov-commenter
Copy link

codecov-commenter commented Jun 8, 2023

Codecov Report

Patch coverage: 97.14% and project coverage change: +0.82 🎉

Comparison is base (2a2c548) 84.28% compared to head (b9a4ead) 85.11%.

❗ Current head b9a4ead differs from pull request most recent head 3de3321. Consider uploading reports for the commit 3de3321 to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #326      +/-   ##
==========================================
+ Coverage   84.28%   85.11%   +0.82%     
==========================================
  Files          29       29              
  Lines        3520     3622     +102     
==========================================
+ Hits         2967     3083     +116     
+ Misses        553      539      -14     
Flag Coverage Δ
cpp 85.11% <97.14%> (+0.82%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
src/memray/_memray/snapshot.h 95.45% <ø> (ø)
src/memray/_memray/snapshot.cpp 93.70% <97.14%> (+1.82%) ⬆️

... and 5 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

@godlygeek godlygeek marked this pull request as ready for review June 9, 2023 14:06
Copy link
Member

@pablogsal pablogsal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Update `HighWaterMarkAggregator` to be able to report on the high water
mark within each snapshot, instead of only the overall high water mark.

Signed-off-by: Matt Wozniski <mwozniski@bloomberg.net>
Add a `TemporalHighWaterMarkAggregatorTestHarness` to the extension
module, and use this to introduce a series of tests proving that we can
correctly track the high water mark within each snapshot.

Signed-off-by: Matt Wozniski <mwozniski@bloomberg.net>
Currently Memray will never produce this type of report, but a future
commit will modify the flamegraph reporter to begin writing HTML files
that use this type of report.

Signed-off-by: Matt Wozniski <mwozniski@bloomberg.net>
Allow `memray flamegraph` to accept the `--temporal` argument without
`--leaks` in order to generate a temporal high water mark report.

Signed-off-by: Matt Wozniski <mwozniski@bloomberg.net>
@godlygeek godlygeek merged commit ee8fe6f into bloomberg:main Jun 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants