profiler
profiler copied to clipboard
Hidden time ranges are not removed from counter data when sanitizing a profile
Sanitizing a profile with "Include hidden time range" unchecked doesn't sanitize counters.
Example profile: https://share.firefox.dev/3Qlfahr
This was a long profile that I couldn't upload because it weighted 78.4MB. I shared it with only a 1189s range. Once shared, I see the power and memory counter for the entire initial profile are present and the full range of the new profile has the entire duration of the original profile
I don't think this is because of the counter data that we preserve. Initially I didn't remove the counter data during sanitization since we don't have any PII in them (we can still remove them if we think that it could reduce a lot of in profile size). But we don't rely on the counter data while determining the timeline range. getTimeRangeIncludingAllThreads computes the timeline range and it calls _getTimeRangeForThread for each thread eventually. See that function:
https://github.com/firefox-devtools/profiler/blob/2431ece540c1375598a4ad27898b46fdf66d7aec/src/profile-logic/profile-data.js#L808-L816
Since profile doesn't have any sample information we are looking at the marker data to calcuate the time range. I wonder if there is a retained marker somewhere that's causing this.
Yeah, some of the Timer threads have such markers.
Even though, our initial problem could be about markers, let's keep this bug for sanitizing the counter data.
Looks like currently we remove the counters completely only when their threads are removed too: https://github.com/firefox-devtools/profiler/blob/b01f70acb0bb8a7b9a670069262fd701729877e9/src/profile-logic/sanitize.js#L154-L170
For filtering the counters to the time range: filterThreadSamplesToRange could be a help on to see how we filter the samples for the thread: https://github.com/firefox-devtools/profiler/blob/b01f70acb0bb8a7b9a670069262fd701729877e9/src/profile-logic/profile-data.js#L1315
Currently it only accepts a thread, but we are going to do similar things, that's why can reuse some parts of that function.
Also we need to reuse getSampleIndexRangeForSelection to find the start and end sample indices.