Convert some code to use the non-inverted call node table even while we're showing the inverted call tree#4899
Merged
Conversation
mstange
changed the title
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #4899 +/- ##
==========================================
+ Coverage 88.42% 88.43% +0.01%
==========================================
Files 304 304
Lines 27186 27189 +3
Branches 7331 7328 -3
==========================================
+ Hits 24039 24045 +6
+ Misses 2929 2926 -3
Partials 218 218 ☔ View full report in Codecov by Sentry. |
mstange
force-pushed
the
fast-invert-preparation
branch
from
992e8aa to
846c195
Compare
julienw
approved these changes
Jan 25, 2024
julienw
left a comment
julienw
left a comment
Contributor
There was a problem hiding this comment.
Thanks, this seems to work perfectly and I understood it all 😆
Comment on lines
+67
to
71
| for (let i = 0; i < nonInvertedCallNodeTable.depth.length; i++) { | ||
| if (nonInvertedCallNodeTable.depth[i] > maxDepth) { | ||
| maxDepth = nonInvertedCallNodeTable.depth[i]; | ||
| } | ||
| } |
Contributor
There was a problem hiding this comment.
This makes me think there's a maxDepth property in the call node table, could we use it directly?
Contributor
There was a problem hiding this comment.
(not especially in this PR though)
Contributor
Author
There was a problem hiding this comment.
Oh I forgot about that property, but you're right!
| threadsKey, | ||
| callNodePath.slice(0, 1), // Select a root node | ||
| { source: 'auto' }, | ||
| callNodePath // Expand the full path |
Contributor
There was a problem hiding this comment.
Ah, this makes me think we might want to do that as well when switching from non-inverted to inverted.
(looking at the code, it looks like we're trying to do it but it's buggy)
Flame graph code is always executed with a non-inverted CallNodeInfo, so getNonInvertedCallNodeTable always returns the same as getCallNodeTable. The purpose of this patch is to remove more callers of getCallNodeTable() without changing behavior.
…guaranteed to have a non-inverted call node info. In these three functions we've already checked whether the CallNodeInfo is inverted. We only get here if it's the non-inverted CallNodeInfo. So getStackIndexToNonInvertedCallNodeIndex will return the same as getStackIndexToCallNodeIndex.
This replaces selectLeafCallNode and selectRootCallNode with a new action creater called selectSelfCallNode which handles both the inverted and the non-inverted case.
mstange
force-pushed
the
fast-invert-preparation
branch
from
846c195 to
806dd22
Compare
Merged
julienw
added a commit
that referenced
this pull request
Feb 6, 2024
[@canova Nazım Can Altınova] Return null instead of throwing an error if it fails to get the resource name in active tab view (#4905) [@fqueze Florian Quèze] Improve the precision of the getFittedText implementation. (#4893) [@fqueze Florian Quèze] Show marker count next to the marker name in the marker chart when a marker is hovered. (#4892) [@mstange Markus Stange] Convert some code to use the non-inverted call node table even while we're showing the inverted call tree (Merge PR #4899) [@canova Nazım Can Altınova] Bring the max stacking depth limit back for marker timings (#4898) [@mstange Markus Stange] Various preparations in call tree code for fast inverted tree (Merge PR #4897) [@mstange Markus Stange] Move call node path/index conversion functions into CallNodeInfo (Merge PR #4896) [@mstange Markus Stange] Make mergeFunction fast (Merge PR #4895) [@gthb Gunnlaugur Thor Briem] feat: support from-url profiles in compare (#4875) And all the locale contributors: de: Michael Köhler el: Jim Spentzos en-GB: Ian Neal es-CL: ravmn fr: Théo Chevalier fy-NL: Fjoerfoks ia: Melo46 it: Francesco Lodolo [:flod] nl: Fjoerfoks, Mark Heijl pt-BR: Marcelo Ghelman ru: Valery Ledovskoy sv-SE: Andreas Pettersson uk: Artem Polivanchuk zh-CN: 你我皆凡人, Olvcpr423, Pontoon zh-TW: Pin-guang Chen
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
To make inverting the call tree fast, we need to stop computing the entire inverted call node table upfront. However, we have many places in the code which work on the call node table directly.
Luckily, many of these places can be changed to use the non-inverted call node table instead. There are three types of code which can be changed like this:
computeXYZNonInvertedfunctionsThe non-inverted call node table is completely sufficient for computing the call path of a sample.
This PR converts the places listed above to use the non-inverted call node table.
An unfortunate aspect of this PR is the fact that the
IndexIntoCallNodeTabletype now becomes quite ambiguous. It can be an index into the inverted or into the non-inverted call node table, often depending on context. This is going to be confusing for readers of the code, and if you use the index in the wrong table there's nothing that catches that mistake.I haven't found a solution to this problem yet. For now I think we should accept the ambiguity, get to the end of the fast-invert work, and then think of a solution that makes sense once that's all done.