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

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


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

Android Nexus6 WebView Perf

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

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

Roll AFDO from 70.0.3528.0_rc-r1 to 70.0.3529.0_rc-r1 by afdo-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com
https://chromium.googlesource.com/chromium/src/+/22dd0f50a181759fdd5cb9be0bcea56ea9a762ce
7.267 → 7.624 (+0.3564)

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

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

Looks mostly (if not entirely) recovered by the following AFDO roll in r585229.

I only see three other AFDO-induced swings like this one in the history of this benchmark (one of which was the 3512 profile, which was a really bad profile all-around). While I'd love a world without noise, that seems within reason to me.

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.