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

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


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

chromium-rel-mac11

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

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

Hi brettw@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 : Brett Wilson
  Commit : 3137bc1dadcd882c878b9218cab4c418cfc35862
  Date   : Tue Sep 19 22:23:37 2017
  Subject: Convert queue and deque to base ones in //media

Bisect Details
  Configuration: mac_10_11_perf_bisect
  Benchmark    : media_perftests
  Metric       : clockless_playback/sfx_u8.wav
  Change       : 8.61% | 11384.7914435 -> 10404.7543826

Revision             Result                  N
chromium@502874      11384.8 +- 442.579      6      good
chromium@502924      11190.9 +- 475.324      6      good
chromium@502949      11148.7 +- 438.381      6      good
chromium@502962      11335.0 +- 508.387      6      good
chromium@502968      11249.2 +- 498.455      6      good
chromium@502970      11141.1 +- 215.755      6      good
chromium@502971      10429.9 +- 437.211      6      bad       <--
chromium@502974      10404.8 +- 337.191      6      bad

To Run This Test
  ./src/out/Release/media_perftests --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/8967098030920168720


For feedback, file a bug with component Speed>Bisection

I spent several hours looking at this. I notice no other bots or video streams in the same test seem to have shown the same regression.

I checked the deque usage of this test and it is not doing anything weird. Some code does do erase from the front which was much slower because of  bug 769812 . That bus is now fixed but it doesn't appear to show in the graph. I'm also skeptical this would have made much difference for this particular test since the queue sizes are small (that bug showed a 10x regression for a 35 million entry queue).

A couple particular deque replacements showed some differences in local tests, I'm going to try to put back just those and see if the regression is fixed.

Eh, I think you can just ignore this. Or at least your proposed revert doesn't affect this code path at all. These tests have shown sensitivity to changes in linkage in the past unfortunately, so this might just be noise.

See crbug/767124. I will remove this test from alerting.