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

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


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

webrtc-mac-large-tests

Can you please have a look whether https://codereview.webrtc.org/2355503002/ 
is the cause for this change and verify if it is expected. 

Taking a look at it. This test heavily tests an "unloaded" NetEq path (i.e. no time is spent decoding, just passing silent PCM frames through NetEq) so even small changes can cause changes to that performance graph. It's previously been the case that making DecoderDatabase::IsComfortNoise less efficient causes perf regressions, just because it's hit several times for each packet called. It's quite possible that this change does make IsComfortNoise (and similar checkers like IsRed and IsDtmf) slightly slower.

I've created a CL at https://codereview.webrtc.org/2383723002/ that reduces the time to check whether a payload type is CN, RED or DTMF by mapping that before-hand. I'm still leaving it a bit open for now. It might be better addressed once we're done with the current remodeling.

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/9f38c218ee0282042e5bc31d3d3a1b1f53e4be16

commit 9f38c218ee0282042e5bc31d3d3a1b1f53e4be16
Author: ossu <ossu@webrtc.org>
Date: Tue Oct 04 12:23:32 2016

Cache the subtype of each DecoderInfo to make the Is* checks quicker.

Addresses a regression in the NetEq performance test.

# Added NOTRY due to android_arm64_rel being swamped.
NOTRY=True
BUG= chromium:651426 

Review-Url: https://codereview.webrtc.org/2383723002
Cr-Commit-Position: refs/heads/master@{#14495}

[modify] https://crrev.com/9f38c218ee0282042e5bc31d3d3a1b1f53e4be16/webrtc/modules/audio_coding/neteq/decoder_database.cc
[modify] https://crrev.com/9f38c218ee0282042e5bc31d3d3a1b1f53e4be16/webrtc/modules/audio_coding/neteq/decoder_database.h

Looking at the graph since 14495 landed, it looks like we're now back to the same baseline as before. Setting this as fixed.

 Issue 653136  has been merged into this issue.

The CL in #5 landed in M55, so updating the milestone accordingly.