Stop treating import calls as import system frames #329
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Up until now, our code has been treating the last location before the
import system is entered as an import system location as well, in order
to hide the
import
statement itself when the user clicks the "HideImport System Frames" checkbox.
There's a few problems with that approach, though. For one, there may be
other calls on the same line that lead to other, non-import system
allocations. For instance, the user may do something like:
We don't want to hide that line on the flame graph, or users will lose
visibility into the
mmap.mmap
call when they try to hide imports.A subtler problem with this approach is that we only handled the frame
with the
import
statement as an import system frame if the first childwe saw from it was an import system frame. Assuming it had a mix of some
descendants that are in the import system and some that aren't, our
behavior would change based on the order that the reporter received
those in (and the order that the reporter receives allocations in is
arbitrary and not guaranteed to be stable across runs).
Fix this by never hiding the
import
statement itself.Also, add some micro optimizations here. These optimizations speed up
flamegraph generation by about 15% (for the nbody example, native mode).