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

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


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

Android Nexus5 Perf
android-nexus5x-perf
linux-perf

rasterize_and_record_micro.top_25 - Benchmark documentation link:
  None

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

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/1490568b640000

Roll AFDO from 70.0.3535.0_rc-r1 to 70.0.3536.0_rc-r1 by afdo-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com
https://chromium.googlesource.com/chromium/src/+/e27e4baa22caa10779013f639a339a92bff27916
8.558 → 16.47 (+7.916)

Assigning to sheriff gbiv@chromium.org because "Roll AFDO from 70.0.3535.0_rc-r1 to 70.0.3536.0_rc-r1" is a roll.

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

Benchmark documentation link:
  None

I'm on vacation right now, so my time to look into this is limited. My notes:

- Linux has recovered, though Android hasn't (yet).
- Linux had an apparently AFDO-related spike at r584698 (around 1-2 weeks ago), which recovered the next day
- Linux and Android have no obvious recent AFDO-related noise, modulo the comment above.

I'll keep this on my queue for when I get back, but generally the expectation is for things like this to sort themselves out after a few profile rolls. We'll see if that happens, I guess. :)