1756519 - The base profiler doesn't collect CPU time, and the front-end workaround for missing CPU deltas gives misleading results

Status: NEW

(Core :: Gecko Profiler, defect, P2)

Description

[Florian Quèze [:florian]]

I got 2 Windows startup profiles today where the max CPU percentage used in the parent process main thread was significantly lower during the base profiler part.

https://share.firefox.dev/3H7SnjH - 2 cores machine
https://share.firefox.dev/3H4qN6N - 6 cores machine

It's theoretically possible that the CPU wasn't used at 100% during the base profiler part of startup... but the timeline looks pretty flat (especially on the 6 core machine where it seems to be always between 40 and 43%) so it would be surprising.

Comment 1

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

Well, the Base Profiler doesn't take any CPU measurements at all!
For example, in https://share.firefox.dev/3H7SnjH profile.threads[0].samples.threadCPUDelta starts wtih 162 null values.
I'm guessing the front-end falls back to the old algorithm in this case, using idle stack frames to estimate the CPU load.

It should be possible to port all the RunningTImes code, to get consistent measurements between profilers.
It's probably more important now that Base Profiler samplings are just blended with the Gecko Profiler ones.

Comment 2

[Julien Wajsberg [:julienw]]

"The old algorithm" is as if the CPU is always at 100%. Bu that's not what happens int his case. Indeed if there's any CPU information in the thread, even if it's way later, we'll try to use it.

Therefore what we're doing is taking the closest CPU information for a sample, this means in this case the first CPU information we have in this profile. And because we use that for all these null samples, everything happens as if this CPU information is the max (instead of 100% like before), and the algorithm using categories that hides the idle category is used on top of that. That's why everything looks smaller.

There are 2 ways to fix that:

1. obviously, make the base profiler collect CPU data as well.
2. fix the frontend algorithm that tries to find CPU data -- but the solution isn't obvious.

Would that be difficult to make the base profiler collect CPU data?