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

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


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

linux-perf

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

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

Roll AFDO from 69.0.3450.0_rc-r1 to 69.0.3472.0_rc-r1 by afdo-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com
https://chromium.googlesource.com/chromium/src/+/7eda12e57a46ddd8104cfe440bd66f41c2e573c4
2359 → 2605 (+246.1)

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

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

Looks like the previous 11ish% improvement was due to an AFDO roll, so I'm considering this to be AFDO-induced noise. This appears to be the fourth big AFDO-related swing for this benchmark, so I'll tack this on to my investigations in issue 849881.

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.