All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=855479

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=4b8f0dbc084bc1193ac7e0cd2168bce2b351eb9247b8e209beb2736f78ae2d03


Bot(s) for this bug's original alert(s):

android-nexus5X

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/15905973240000

📍 Found significant differences after each of 2 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/15905973240000

Android/viz: Don't allocate a new LocalSurfaceId after each activation by samans@chromium.org
https://chromium.googlesource.com/chromium/src/+/bb67bf56b4b5d4cb0a32b8376eee5e740db220d3
0.1481 → 0.1476 (-0.0005125)

Revert AFDO to 69.0.3450.0_rc-r1 by gbiv@chromium.org
https://chromium.googlesource.com/chromium/src/+/599a9e359e2d7da2e00b490fad9af5d50b1385a7
0.1478 → 0.1545 (+0.006667)

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Ack; we generally like keeping profiles fresh, since older profiles == a slower Chrome.

I plan on restarting the autoroller early next week (after we've verified that the bug motivating the revert to 3450 is fixed). I'll keep an eye on this afterward to verify that it recovers.

These appear to be back to normal as of the rolls in r570151 (first graph) / r570361 (second graph).