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

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


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

linux-release

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

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

Roll clang 321529:324578 by hans@chromium.org
https://chromium.googlesource.com/chromium/src/+/ca5066b992b8a05e6a3df042f2c0e1766e13a565

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

This is interesting.

audio_bus_to_interleaved/int16_t, regressed by 10%
but audio_bus_to_interleaved/float improved 11%, fixing  crbug.com/801240 

Looking at the graphs historically, this kind of 1ms movements on the benchmark seems pretty common. See  crbug.com/793835  for a recent example.

My guess is that these are microbenchmarks that are sensitive to when the code moves around.

I don't think there's anything actionable here.

Thanks hans@!

I edited the anomaly config to only alert on 15% or higher change.