[Perf] 20% regression in cpuTime/system_health.common_desktop after cr128

[atuchin-m]

Alert information:
Median of segment before: 2016.97
Median of segment after: 2431.657
Relative change: 20.6%
Test: BravePerf/win11-hp-laptop-typical/system_health.common_desktop/cpuTime:all_processes:all_threads:all_stages:all_initiators/load_chrome/load_chrome_blank

[atuchin-m]

• the same regression for Chromium, but the spike is less: https://brave-perf-dashboard.appspot.com/report?sid=83398edcf3386ae6f5165c2d2dd737240b83810491020d9cfeb5c70f6048ae56&rev=20544
• the detailization shows no changes for the browser process, the main diff is located in render_processes: https://brave-perf-dashboard.appspot.com/report?sid=a0a421a108bc33a0ca0449bdd89dc91d463252c01c94a74bc09b8566beadf2e4&rev=20544
• the cpu usage before the regression looks unrealistic (8-10ms for all the process). The new values are more adequate (75ms chrome, 150ms brave).
• the traces doesn't show any expected events (render frame initialization) before the regression.
• this can be about:blank specific. Some filter could just cut some event and it could be changed after cr128 is merged.

[atuchin-m]

A test build with example.com: https://ci.brave.com/job/brave-browser-test-perf-macos/2010/

[atuchin-m]

[atuchin-m]

The traces show that one of the reasons of the regression is that we don't count Brave Extension frame load work before and start to could after. There is also a difference how tracing mechanism classify the renderers (see the screenshot). We actually want to count it, so the new behavior is correct one.

But it doesn't explain changing in the reference (chromium) metrics. However, the ref diff isn't so significant.

[atuchin-m]

A test win build with chromium: https://ci.brave.com/job/brave-browser-test-perf-windows/1009/