Sidebar category breakdown behaves oddly when looking at allocation call trees #5331
Assignees
Labels
allocations
Issues related to the JS or native allocation feature
profile data
Issues related to the profile format, data structure, or profile upgraders
timeline
Issues related to the header timeline view
Comments
mstange
added a commit
to mstange/perf.html
that referenced
this issue
Jan 17, 2025
…iltered call tree summary strategy samples when using an allocation strategy. Fixes firefox-devtools#5331. Let's say we allocate 100 objects, and then free the first 50 of them. If you look at the entire thread, the `retained-native-allocations` view will show the allocation samples for the second 50 objects (the one's that weren't freed). If you look at just the part of the thread where you allocated, you will see allocation samples for all 100 objects (because none were freed in that part of the thread). How do you get the stack category for each of the 100 allocation samples, especially if you've applied transforms or a JS-only filter? You need to look at the stack of the raw nativeAllocations table. You cannot look at the `retained-native-allocations` of the entire thread, because that table doesn't have the stacks for the first 50 objects - it nulls those stacks out because it knows that those objects have been deallocated. This commit makes it so that the unfilteredCtssSamples are just the raw allocation tables, when an allocation-related call tree summary strategy is selected. The unfilteredCtssSamples can be used to look up the stack, and therefore the original category of a sample, based on the sample index in the filtered (or preview-filtered) CTSS samples table. We should not create a call tree just based on the unfilteredCtssSamples because these samples have not been filtered according to the strategy.
mstange
added a commit
to mstange/perf.html
that referenced
this issue
Jan 17, 2025
…iltered call tree summary strategy samples when using an allocation strategy. Fixes firefox-devtools#5331. Let's say we allocate 100 objects, and then free the first 50 of them. If you look at the entire thread, the `retained-native-allocations` view will show the allocation samples for the second 50 objects (the ones that weren't freed). If you look at just the part of the thread where you allocated, you will see allocation samples for all 100 objects (because none were freed in that part of the thread). How do you get the stack category for each of the 100 allocation samples, especially if you've applied transforms or a JS-only filter? You need to look at the stack of the raw nativeAllocations table. You cannot look at the `retained-native-allocations` of the entire thread, because that table doesn't have the stacks for the first 50 objects - it removes those samples because it knows that those objects have been deallocated. This commit makes it so that the unfilteredCtssSamples are just the raw allocation tables, when an allocation-related call tree summary strategy is selected. And it makes it so that `extractSamplesLikeTable` always returns a table that has compatible indexes to the `extractUnfilteredCtssSamples`, just with some samples having a null stack. Now the unfilteredCtssSamples can be used to look up the stack, and therefore the original category of a sample, based on the sample index in the filtered (or preview-filtered) CTSS samples table. We should not create a call tree just based on the unfilteredCtssSamples because these samples have not been filtered according to the strategy.
mstange
added a commit
to mstange/perf.html
that referenced
this issue
Jan 17, 2025
…iltered call tree summary strategy samples when using an allocation strategy. Fixes firefox-devtools#5331. Let's say we allocate 100 objects, and then free the first 50 of them. If you look at the entire thread, the `retained-native-allocations` view will show the allocation samples for the second 50 objects (the ones that weren't freed). If you look at just the part of the thread where you allocated, you will see allocation samples for all 100 objects (because none were freed in that part of the thread). How do you get the stack category for each of the 100 allocation samples, especially if you've applied transforms or a JS-only filter? You need to look at the stack of the raw nativeAllocations table. You cannot look at the `retained-native-allocations` of the entire thread, because that table doesn't have the stacks for the first 50 objects - it removes those samples because it knows that those objects have been deallocated. This commit makes it so that the unfilteredCtssSamples are just the raw allocation tables, when an allocation-related call tree summary strategy is selected. And it makes it so that `extractSamplesLikeTable` always returns a table that has compatible indexes to the `extractUnfilteredCtssSamples`, just with some samples having a null stack. Now the unfilteredCtssSamples can be used to look up the stack, and therefore the original category of a sample, based on the sample index in the filtered (or preview-filtered) CTSS samples table. We should not create a call tree just based on the unfilteredCtssSamples because these samples have not been filtered according to the strategy.
canova
added
timeline
mstange
added a commit
that referenced
this issue
Jan 20, 2025
…iltered call tree summary strategy samples when using an allocation strategy (#5332) Fixes #5331. Let's say we allocate 100 objects, and then free the first 50 of them. If you look at the entire thread, the `retained-native-allocations` view will show the allocation samples for the second 50 objects (the ones that weren't freed). If you look at just the part of the thread where you allocated, you will see allocation samples for all 100 objects (because none were freed in that part of the thread). How do you get the stack category for each of the 100 allocation samples, especially if you've applied transforms or a JS-only filter? You need to look at the stack of the raw nativeAllocations table. You cannot look at the `retained-native-allocations` of the entire thread, because that table doesn't have the stacks for the first 50 objects - it removes those samples because it knows that those objects have been deallocated. This commit makes it so that the unfilteredCtssSamples are just the raw allocation tables, when an allocation-related call tree summary strategy is selected. And it makes it so that `extractSamplesLikeTable` always returns a table that has compatible indexes to the `extractUnfilteredCtssSamples`, just with some samples having a null stack. Now the unfilteredCtssSamples can be used to look up the stack, and therefore the original category of a sample, based on the sample index in the filtered (or preview-filtered) CTSS samples table. We should not create a call tree just based on the unfilteredCtssSamples because these samples have not been filtered according to the strategy.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Profile: https://share.firefox.dev/4ao9Kgn
When dragging a selection and watching the category breakdown in the sidebar, sometimes the values stop updating.
Or if you zoom in: https://share.firefox.dev/4g4zM9N
Here the category breakdown has a lot of blue in it even though it should only have green.
I think this is because of the issue I pointed out in #5330. Every time we create an allocations-related SamplesLikeTable, we make a completely new table whose sample indexes have nothing to do with the unfiltered table. Translating between them using an index offset is not possible.
In this profile, the
native-retained-allocationstable for the unfiltered thread has 200 entries. But if you make a preview selection which starts at the beginning but which doesn't contain the deallocations at the end, thenative-retained-allocationstable for the preview filtered thread has 400 entries!┆Issue is synchronized with this Jira Task
The text was updated successfully, but these errors were encountered: