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

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


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

Android Nexus6 WebView Perf

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

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

Roll AFDO from 70.0.3513.0_rc-r1 to 70.0.3514.0_rc-r1 by afdo-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com
https://chromium.googlesource.com/chromium/src/+/07987725b8d4091cb2efe7b776e191efd8ae0a1d
88.19 → 64 (-24.19)

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

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

Sigh. Looks like more recent afdo-induced flakiness (see also  issue 872168  and  issue 872165 ).

Please note, though, that the most recent drop (at r581372) was due to a revert to a few-days-old AFDO profile to help triage a bug. We've since turned the autoroller back on, so the most recent profiles might have stabilized.

I'm wrapping up an investigation about how AFDO interacts with binary size now. I'll keep an eye on this graph, and if it keeps fluctuating, make it the next thing on my list.

 Issue 872158  has been merged into this issue.

Looks stable + back to pre-regression levels again