New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 621580 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Jun 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

2.6%-16.7% regression in webrtc_perf_tests at 13191:13193

Project Member Reported by terelius@chromium.org, Jun 20 2016

Issue description

There was a fairly sharp perf (but not dramatic) regression in the screenshare stats, with dropped frames increasing from ~18 to ~21 on nexus5 and encode usage increasing from ~35.8% to ~36.7% on windows.

The change was blamed on https://chromium.googlesource.com/external/webrtc/+/57c21f9b44621b6415d81d353923eb3975276703
by the perf alerts, so I'm assigning to Per for a closer look.

The nearby Chromium roll (including some libvpx change) https://chromium.googlesource.com/external/webrtc/+/0dbc8bfbe52af4699714108d875adcdd8543d63c
appears to be outside the range that could possibly cause the regression (but I didn't dig very deep into that).
 
All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=621580

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgwtTvuAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICggoPmpQoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgwvCUqQoM


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

webrtc-android-tests-nexus5
webrtc-linux-large-tests
webrtc-win-large-tests

Comment 2 by perkj@chromium.org, Jun 27 2016

Cc: sprang@chromium.org

Comment 3 by perkj@chromium.org, Jun 27 2016

Status: WontFix (was: Assigned)
Discussed with sprang.
These tests are apparently timing sensitive. My cl move the call to start the encoder from one thread to the encoder thread and might change the timing a bit. 
The observed performance numbers are so small that timing explains the change. 

Sign in to add a comment