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

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


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

android-one

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

📍 Found significant differences after each of 2 commits.
https://chromeperf.appspot.com/job/12d731c7840000

Roll AFDO from 66.0.3336.3_rc-r1 to 66.0.3345.0_rc-r1 by afdo-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com
https://chromium.googlesource.com/chromium/src/+/7645aecdf4f5d20b53c1f5efa2925a5772f40f02

Add console messages for HTTPS UI experiment by cthomp@chromium.org
https://chromium.googlesource.com/chromium/src/+/3bafd2d7542c4d85c8e3f1e2047c4145c78307ea

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

It looks like the AFDO roll change happened before my console message change, and seems much more likely to be responsible for any perf effects, but I'm not familiar with what this particular benchmark is testing.

+cc-ing the benchmark owners to help clarify/investigate.

+gbiv who appears to own the AFDO auto-roll.

Ack. It appears that some blink benchmarks are pretty sensitive to the AFDO profile's contents, and we roll a new AFDO profile (roughly) every day.

I'll keep watch of this, and if it doesn't get better after the next few rolls, fold it into my blink TODO on issue 799629.

Looks like this AFDO roll just 'undid' an improvement from the prior AFDO roll ( issue 820776 ). Since the benchmark has been pretty stable for the last N rolls, I'm considering the original improvement to be a transient issue.

Since we had another blip recently in  issue 820107 , I'll ping the AFDO pipeline maintainers to see what we can do to figure out why this is happening.