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

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


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

android-nexus5

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

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

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

Roll AFDO from 67.0.3379.0_rc-r1 to 67.0.3390.0_rc-r1 by afdo-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com
https://chromium.googlesource.com/chromium/src/+/c1e3fa4c733bf46e284e257377b5443bdb549910

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

Assigned based on comment in pinpointed CL.

Yikes. This benchmark in general seems to be really sensitive to the AFDO profile. The most recent two big 'mountains' (first starting at '555524 - 555695' and ending at '555994 - 556013', second starting at '556349 - 556352' and ending at '556379 - 556389' all appear to be with AFDO profile rolls one day apart. If we look back farther, it looks like every massive swing upwards/downwards after (and including) '532471 - 532552' is the result of an AFDO roll.

I'll look into if there's any way to smooth this out.