Compute cpuRatio values when computing the derived thread

[mstange]

Production | Deploy preview

processThreadCPUDelta makes it so that the threadCPUDelta column doesn't have any null values. However, the type of the threadCPUDelta column still looks as if values could be null.
Now that we have a derived Thread type, we can change the type so that it expresses that the values can't be null. So we move the call to processThreadCPUDelta a bit earlier in the derivation pipeline so that all the types work out.

Even better, we can compute CPU ratios at this point, and not even store the "clamped and non-null cpu delta" values.

And since we're doing that, I'm changing the behavior for null cpu delta values: Rather than using the closest non-null cpu delta and spreading it over a potentially-different sample time delta, just set the cpu ratio to 1. The only known cause of null values (other than the first value, which we ignore) is the base profiler, and we want CPU percentage to be reported as 100% during the base profiler time.

Fixes #4072.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 85.93%. Comparing base (b4430d0) to head (3f0926c).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5288      +/-   ##
==========================================
- Coverage   85.93%   85.93%   -0.01%     
==========================================
  Files         311      312       +1     
  Lines       29812    29771      -41     
  Branches     8222     8196      -26     
==========================================
- Hits        25620    25583      -37     
+ Misses       3601     3597       -4     
  Partials      591      591              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[canova]

Looks good to me! Thanks for the changes.

[canova]

For the last sample, afterSampleCpuRatio will be always 1, right? Is this correct or do we maybe want to use the same value as beforeSampleCpuRatio?

[mstange]

I'll do what you suggested. I don't think there's a clear answer because we just don't have the information about what happens after the last sample.

[mstange]

I think we set the "after last" duration to the interval, so it's true that it would be weird to make it look as if there was 100% CPU for one interval after the last sample. Defaulting to zero would make more sense. But defaulting to beforeSampleCpuRatio also sounds fine.

[mstange]

Oh, using beforeSampleCpuRatio is also what we do in _accumulateSampleCategories, so yes this would make hit testing consistent with rendering.

[canova]

Hm why do we zero out the first value? I vaguely remember something related to that but forgot. It might be good to add a comment about it as well.

[mstange]

Hmm I thought I had written a comment somewhere but I can't find it now. Yes I'll add a comment.

Changing this as follows:

diff --git a/src/profile-logic/cpu.js b/src/profile-logic/cpu.js
index 24eb84e7aa..a16a394ad7 100644
--- a/src/profile-logic/cpu.js
+++ b/src/profile-logic/cpu.js
@@ -123,8 +123,13 @@
   }
 
   const threadCPURatio: Float64Array = new Float64Array(threadCPUDelta.length);
+
+  // Ignore threadCPUDelta[0] and set threadCPURatio[0] to zero - there is no
+  // previous sample so there is no meaningful value we could compute here.
   threadCPURatio[0] = 0;
 
+  // For the rest of the samples, compute the ratio based on the CPU delta and
+  // on the elapsed time between samples (timeDeltas[i]).
   for (let i = 1; i < threadCPUDelta.length; i++) {
     const referenceCpuDelta = maxThreadCPUDeltaPerMs * timeDeltas[i];
     const cpuDelta = threadCPUDelta[i];