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

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


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

Android Nexus6 WebView Perf

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

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

Roll AFDO from 70.0.3524.0_rc-r1 to 70.0.3524.2_rc-r1 by afdo-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com
https://chromium.googlesource.com/chromium/src/+/690223f18e5abd6430c467e884cac9ccf34dfbd7
89.72 → 63.65 (-26.08)

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

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

Looks like we're back to normal, though I'll note that there was also some afdo-related noise in the recent past for this benchmark (one of the three consecutive-ish dips was caused by a revert to an old AFDO profile, so really, only two of the profiles were problematic).

I'll close this for now, but if I get many more issues about this benchmark regressing, I'll see if we can stabilize it.

(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 in general is being tracked in issue 849881.)