Major startup regression in ExtensionService::Init() starting in 59.0.3067.0 |
|||
Issue descriptionExtensionService::Init() is 200% slower at the 75th percentile starting in 59.0.3067.0. This also appears to be contributing to a regression in message loop start time. https://uma.googleplex.com/p/chrome/timeline_v2?sid=ed4ea4efdbff8e5797716bed45705c2e (Note: top graph is plotting 75th percentile, bottom message loop graph is plotting 25th percentile, where the effect is more significant.) The sampling profiler difference between 59.0.3066.0 and 59.0.3067.0 appears to show much of the additional time being spent in permissions-related extension functions: https://uma.googleplex.com/p/chrome/callstacks?sid=a6644ae51e146d1ebab7ebe73baa673d
,
Apr 14 2017
Hmm... Looking at the timeline now, it seems like these are back to normal in 59.0.3070.0: https://uma.googleplex.com/p/chrome/timeline_v2?sid=2c477e29a5a8a6cce0c4ed6b38eaa378 Also, looking through the changelog for 3066 to 3067 (where the regression supposedly happened), the *only* extensions-related changes are revision b0bf8e8ed34ba40acece03baa19446a5d91b009d (chromeos: Move //ash/common files into //ash) and revision 1c4d759e44259650dfb2c426a7f997d2d0bc73dc (The Great Blink Rename of 2017). Neither of those should have had any impact... Is there any reason we'd see significant noise in these metrics? https://chromium.googlesource.com/chromium/src/+log/59.0.3066.0..59.0.3067.0?pretty=fuller&n=10000
,
Apr 14 2017
I didn't see anything obviously contributing in the change log either... I also don't see any Finch changes that would have obviously caused this. It seems unlikely to be noise, given that the the increase was highly consistent for all releases between 3067 and 3069 before apparently dropping down to exactly the prior level in 2070. Could this change have been produced by an update to a widely-used first- or third-party extension?
,
Apr 14 2017
Anything's possible, but I'd be kind of surprised. Extension updates can cause noise in page load times (because content scripts, webRequest, etc), but parsing permissions or just loading them shouldn't be likely to take so much longer.
,
Apr 17 2017
Still don't know what happened here, but the releases over the weekend continue to not have the regression, so I'll go ahead and close. I was suspicious that this could be due to some change that was committed for 3067 then reverted for 3070. But that also didn't pan out: none of the reverts in 3070 that looked potentially relevant correspondeded to commits in 3067. |
|||
►
Sign in to add a comment |
|||
Comment 1 by wittman@chromium.org
, Apr 14 2017