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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg3Mi6tQoM


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

chromium-webrtc-trunk-tot-rel-mac

enne@: FYI, I believe that your CL (https://chromium.googlesource.com/chromium/src/+/9af6c23da7070f9423d5cf25856ed27f7d5d8e5e) caused a perf regression in WebRTC. The landing of the CL and the subsequent revert of it align with a regression and recovery in the graph linked in #1.

Please, take care if you are going to re-land this change.

Thanks for the warning!

How can I locally test that this won't regress when I reland? I am not sure at all what this regression corresponds to in browser tests.

You will first have to add the following solution to your .gclient:
{
  "name"        : "webrtc.DEPS",
  "url"         : "https://chromium.googlesource.com/chromium/deps/webrtc/webrtc.DEPS",
}

Build the browser_tests target in Release mode, and run:
$ out/Release/browser_tests --run-manual --ui-test-action-max-timeout=350000 --gtest_filter=WebRtcPerfBrowserTest.MANUAL_RunsOneWayCall60SecsAndLogsInternalMetricsDefault

Look for the line that starts with "RESULT audio_rates_recvonly: goog_expand_rate". The graph that regressed plots the average of the values in the array that follows.

Run this test with and without your fix. The results are probably machine dependent, so comparing with the perf bot graphs is likely moot. You will have to check your own before-and-after values.

Also, since this was only triggered on Mac, you'll probably have to test it on Mac.

Good luck, and thanks for helping out!