12ms startup performance regression in policy::BrowserPolicyConnectorBase::GetPolicyService() |
||
Issue descriptionData from the UMA Sampling Profiler shows that policy::BrowserPolicyConnectorBase::GetPolicyService() regressed browser process UI thread startup on 64-bit Chrome on Windows by 12ms. This occurred in the 66.0.3335.0 Canary release. The responsible CL appears to be https://chromium.googlesource.com/chromium/src.git/+/76da73abaeede740fc97479c09c92a52972bc477 Profile difference of Canary 66.0.3334.0 vs. 66.0.3335.0: https://uma.googleplex.com/p/chrome/callstacks?sid=074ac54ddafd861b16295a40c6a750c0
,
Feb 7 2018
It looks like I missed the other half of this change due to the changes in higher-level function names. If we look at things at the policy::PolicyLoaderWin::PolicyLoaderWin level, we can see the other half of the change, which actually improved things by 23ms, for a net *improvement* of 12ms: https://uma.googleplex.com/p/chrome/callstacks?sid=f9232e2fadf1ed43d0dfb0b86971eee0 I'll close this since it seems that there's no action to be taken.
,
Feb 7 2018
I actually wouldn't expect any net impact. I just moved code around.
,
Feb 7 2018
It's possible the delta could be due to some other factor (e.g. population shift or a different code change). But there does seem to be a reasonably consistent drop in execution time in policy::PolicyLoaderWin::PolicyLoaderWin starting with 66.0.3335.0. See attached graph of aggregate function execution time of the function across canary builds for the last year (blue points = msvc builds, brown points = clang builds), with the recent drop in the last five builds.
,
Feb 7 2018
It's possible that the ordering change causes different contention characteristics with other things happening in Chrome, which could cause the different performance effect.
,
Feb 7 2018
That could be; the change did move the work from after the child threads are executing to before. |
||
►
Sign in to add a comment |
||
Comment 1 by wittman@chromium.org
, Feb 7 2018