Assigning to kerz@ for triage. I suspect that this issue is already known but filed a bug in case it is not

I haven't found any interesting data in the "UMA timeline" for canary channel (https://uma.googleplex.com/p/chrome/timeline_v2/?sid=c7f098aab6073388c2f95d5852032504)

pkotwicz, not sure why you gave this to me. If you need help with a performance regression, contact the perf sheriffs please.

lanwei appears to be the current perf sheriff

Anecdotally, I did notice that startup is dreadfully slow since yesterday (although I was OOO for a month before that so dont' knwo when the regression started)

Thanks for reporting! I think this is a dupe of bug 623956?

sullivan@ I am not sure if it is a dupe of bug 623956. I did not notice a significant perf hit on Android L but did on Android M. bug 623956 is about Android L (and Mac)

The stats for the 75th percentile of Startup.FirstCommitNavigationTime are really bad and seem to match what I have been seeing locally
https://uma.googleplex.com/p/chrome/timeline_v2/?sid=db2f257166bb22a50ba74fcd2379d753

+pasko since you're familiar with android startup

+perezju we don't have a bot tracking startup on M, right?

No, I don't think we have any bots running perf tests on M today.

Random thoughts, sorted by importance:

0. Does it visually start longer than 13 seconds from an intent or it's the metric that likely got broken?

1. anything special in logcat for the slow build?

2. Since you have the revision ranges, can you do a local bisect on your local device running M build? (last time I tried bisect script did not work locally - in this case file bugs against speed infra plz)

3. might be related to Issue 622213, it also mentions M

I did a manual bisect. The startup regression was fixed by https://codereview.chromium.org/2111233002

:( Yeah, that regression should be component-mode only, so hopefully it didn't show on any meaningful telemetry tests.