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

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


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

Android Nexus5 Perf
android-nexus5x-perf

blink_perf.canvas - Benchmark documentation link:
  https://bit.ly/blink-perf-benchmarks

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

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

Roll AFDO from 70.0.3529.0_rc-r1 to 70.0.3530.0_rc-r1 by afdo-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com
https://chromium.googlesource.com/chromium/src/+/9f547654633778c99e48754b772b75d088f6280a
37.61 → 23.35 (-14.26)

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

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

Yeah... 4 afdo-related dips in a month is starting to seem a bit on the noisy side. (I'm ignoring the `581298 - 581432` drop, since that was a revert to an old profile to help troubleshoot a release blocker).

If this happens much more, I'll see if there's a simple way to make this less bad. 38% is a lot of variance for a single profile roll, yet it seems to be pretty consistent.

In any case, I'll keep this open until we see a roll that unregresses this. Extrapolating, that should probably come in the next few days...

For context, AFDO profiles are generated by sampling Chrome's execution and feeding that back into the compiler, so the compiler can better optimize Chrome. This process is inherently noisy, so we'll sometimes see benchmarks that are highly sensitive to certain optimizations being performed (read: many of blink's benchmarks) swing around from time to time, and we’ll sometimes see Chrome vary in size as the inliner decides to be more/less aggressive. Denoising this is being tracked in issue 849881.

Everything seems OK again after r586612