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

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


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

android-nexus6

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

📍 Found significant differences after each of 2 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/12bc52aac40000

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

[xr] Add a flag for enabling XR hit test support by vollick@chromium.org
https://chromium.googlesource.com/chromium/src/+/7aaccf95fda3415c10feaa5947f6b353045d33e3

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

This CL adds an unused flag. I don't see how this could affect performance.

Brian, any chance this could be related to the roll?

This is not actually a Skia roll but a AFDO roll. It uses the Skia autoroller (which is somewhat confusing).

Ack; thanks.

AFDO profile rolls are known to rarely cause changes in blink benchmarks.

The general opinion when we landed AFOD was "blink regressions are great to use as an indicator when triaging a regression of a higher-level benchmark, but a few blink regressions on their own are too micro-benchmark-y and sensitive to e.g. inlining decisions to provide much signal."

With that in mind, I'm on vacation for a week after today, so I'll let this sit + see if I get any other related bugs in that time. If this is the only complaint I hear, I plan to WontFix this.