+Peter: There were two theme-related changes in canaries compared by the profiler. We're wondering if bumping the theme pack version (https://chromium-review.googlesource.com/c/chromium/src/+/1155486) might have caused the 65ms increase here, as it seems to throw out the cache & rebuild images?

If so, should we expect it to go back down over time?

Thanks!

If this is measuring perf in the field, then I would expect your hypothesis is correct: bumping the version number should cause a startup hit on the first run after that, and then no hit on subsequent runs.

To confirm, if we are able to split by whether users have a custom theme, we should expect to see no startup time change in non-theme users.

(That said, we're bumping the version number a lot lately, so almost every canary release might cause such a regression :P)

Ah, good to know! This is for Canary users on Windows, so possibly a small population. 

I'm not sure if we can split by users who have a theme installed ... will take a look.

If the version is being bumped frequently, I can also look at a comparison of two different Canaries (without our change), to see if the same increase is observable.

Thank you!

It looks like this was indeed due to bumping the theme pack version.

Comparing two versions that included another recent increment (https://crrev.com/c/1157878), a similar increase in browser process UI thread startup (this time, 76.3ms) can be observed:

https://uma.googleplex.com/p/chrome/callstacks?sid=8627ac6ac4dabf0f47fd85ac8559ca21

Since this is caused by cache invalidated & expected, I'm closing this bug as WontFix.


Thanks everyone!

Thanks for the investigation! I'll keep this in mind as an 'expected' performance change case for detecting regressions.

Thanks Mike! I appreciate you keeping us honest :-)