Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8955774951346652240

Started a bisect just for fun, but my best guess here is that I moved a timestamp from Application.onCreate() to Application.attachBaseContext().

Looking at the trace, ChromeApplication.attachBaseContext took only 5ms, and there is a 22ms gap between Startup.BrowserMessageLoopStartTimeFromMainEntry2 and attachBaseContext, which would capture the time for:

super.attachBaseContext(context);
ContextUtils.initApplicationContext(this);
ContextUtils.isMainProcess()
CommandLineInitUtil.initCommandLine()

Of these, the first three are simple getters / setters, and the last one is code that already ran during start-up (but in onCreate() rather than attachBaseContext()).

Within initCommandLine(), I did make one change that would slow it down, which is to call getDebugAppJBMR1() (which does an IPC) rather than short-circuit on BuildInfo.isDebugAndroid(). I think this is better though, as it results in better code coverage, and the slowdown from it won't happen for end-users anyways (unless they have a debug flags file present).


All this to say, if pinpoint comes back and blames my commit, I think we'd be safe to say that it's just a mix of measurement change, and an IPC that won't happen for real users.

ah, indeed that's because we started recording the main entry point earlier. The gap between ChromeApplication.attachBaseContext and ChromeLauncherActivity.onCreate is ~60ms on the trace: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/http___bbc_co_uk_2018-01-31_21-43-49_71329.html

Which debug flags do you refer to?

The gap could be there because of slow java start .. I guess we should investigate why this gap is so big separately.

No specific flag, just the presence of a flags file.

The check to see if you're allowed to use /data/local/temp/chrome-command-line calls getDebugAppJBMR1(), but only if /data/local/temp/chrome-command-line exists in the first place.

The previous trace in the graph shows 15ms between Application.onCreate and ChromeLauncherActivity.onCreate, and shows Application.onCreate taking only .1ms.

So... I think it probably is true that my change slows down initCommandLine() by 15-20ms, but only when a flags file exists. The rest of the delta is from the earlier timestamp.

One of the framework things that happens between attachBaseContext and onCreate is that ContentProviders are created & registered. Might be worth an experiment to see if moving them to a separate process (which would be a huge pain to actually ship) or just deleting them makes start-up go any faster.

I think we can at least mark this bug as fixed?

Thank you for details, Andrew, surely let's close it if there is no slowdown.

One thing to keep in mind is that the associated UMA histograms will shift, though we've been ignoring them on Android anyway, so I'll just ping some magic internal thread to let folks know.

The histograms that will shift are: Startup.BrowserMessageLoopStartTimeFromMainEntry{2,3} and the rest of "Startup*MainEntry*" ones from startup_metric_utils.c