New issue
Advanced search Search tips

Issue 789934 link

Starred by 1 user
Status: WontFix
Owner:
hlundin@chromium.org
Closed: Nov 2017
Cc:
henrika@chromium.org
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

7% regression in webrtc_perf_tests at 20923:20923

Project Member Reported by henrika@chromium.org, Nov 30 2017 
Possible regression in WebRTCPerf/webrtc-mac-large-tests/webrtc_perf_tests / neteq_performance / 10_pl_10_drift

Only CL in range is https://webrtc.googlesource.com/src/+log/4e70a72571dd26b85c2385e9c618e343428df5d3..abbff89b298da3b03cf1f1b23c651f25017ab9b1
Project Member

Comment 1 by 42576172...@developer.gserviceaccount.com, Nov 30 2017 

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

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


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

webrtc-mac-large-tests

Comment 2 by hlundin@chromium.org, Nov 30 2017

Status: WontFix (was: Assigned)
From the test's point of view, the only code changed in the suspect CL is the code in modules/audio_coding/neteq/. And, all that changed in that folder is a small method that got const qualified. This should not affect performance.

Looking at the graph now, it has again gone back to the low level, this time at CL https://webrtc.googlesource.com/src/+/f49a56b1bf6d69af46e56e3a89035898aee92734, which is totally unrelated.

I say this is yet another case of test unreliability.
►

Sign in to add a comment