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

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


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

chromium-rel-win8-dual

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8973799364844794240

=== Auto-CCing suspected CL author jschuh@chromium.org ===

Hi jschuh@chromium.org, the bisect results pointed to your CL, please take a look at the
results.


=== BISECT JOB RESULTS ===
Perf regression found with culprit

Suspected Commit
  Author : Justin Schuh
  Commit : c77d482ba4a8815117ccd6f7f9a5796d3bbe7908
  Date   : Sat Jul 15 21:54:53 2017
  Subject: Fix template bug in base::saturated_cast<>()

Bisect Details
  Configuration: win_8_perf_bisect
  Benchmark    : media_perftests
  Metric       : sinc_resampler_convolve/unoptimized_aligned
  Change       : 3.55% | 29729.5638525 -> 30783.8667695

Revision             Result                  N
chromium@486997      29729.6 +- 304.068      6      good
chromium@486998      30280.2 +- 66.1705      6      bad       <--
chromium@486999      30784.5 +- 144.624      6      bad
chromium@487001      30783.9 +- 142.01       6      bad

To Run This Test
  .\src\out\Release\media_perftests.exe --single-process-tests

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8973799364844794240


For feedback, file a bug with component Speed>Bisection

The change I landed was specific to a narrow subset of Arm configurations, whereas this is Windows. (And for what it's worth, my change was specifically a performance improvement.)

Instead, I'm almost certain this is the impact of Bruce's toolchain update test:
https://chromium.googlesource.com/chromium/src/+/95ebf5a518b2cc7f96046d605057be87ab0e5682

My understanding is that Microsoft changed the behavior of an intrinsic we were relying on, and this is the expected performance regression. Not sure what we want to do about it though.

The graph recovered when the compiler was changed back to VS 2015, so this was unrelated to Justin's change. Closing as WontFix and I'll add a note to the VS 2017 bug.

Also, we're planning on making the switch to Clang in m62, so this should all be moot in the future.

Agreed. Would still be good to understand the issue better in case it informs clang code-gen strategies. It is still (apparently) surprising that we saw such a large regression.