Follow up from internal conversation. The recent refactoring of https://codereview.chromium.org/2694083005 caused some metrics to jump around #453243.
For instance:
https://chromeperf.appspot.com/report?sid=485b53d4a23735f273ef5d7cafdd537d661a1708d04042e2d6b97c2fc7622d09&start_rev=447307&end_rev=453663
Now, good news for speed TPMs, this is not a real regression.
Bad news for the rest: this broke some memory-infra metrics. We should fix it asap, or just revert the CL and reland once fixed is the fix is not trivial.
Copy-pasting some context from the internal conversation:
ssid:
Eshan, can you check why the GetTracingProcessID() call from
GLES2Implementation::OnMemoryDump() returns different values with and
without your change? This should tell what is going wrong.
chiniforooshan:
Umm, my change sets the TPID of the browser process in content::BrowserMain(), before my change it would be lazily set probably in content::BrowserMainRunner::Initialize(). Are there cases that the latter is called but not the former? From the code search I can see that ShellBrowserMain and HeadlessContentMainDelegate::RunProcess might be such cases. Would that explain the regression?
Comment 1 by primiano@chromium.org
, Mar 1 2017