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

Issue 667484 link

Starred by 1 user
Status: WontFix
Owner:
█ hubbe@chromium.org
Last visit > 30 days ago
Closed: Mar 2017
Cc:
█ hubbe@chromium.org
█ watk@google.com
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

15.1%-30.3% regression in media.android.tough_video_cases at 430826:430924

Project Member Reported by w...@chromium.org, Nov 21 2016 
Time to play and cpu utilization regressed for ogv and vp9.
Project Member

Comment 3 by 42576172...@developer.gserviceaccount.com, Nov 21 2016

Cc: hubbe@chromium.org
Owner: hubbe@chromium.org

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

Hi hubbe@chromium.org, the bisect results pointed to your CL below as possibly
causing a regression. Please have a look at this info and see whether
your CL be related.


===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : media: Make sure we transition back to a non-loading state
Author  : hubbe
Commit description:
  
An earilier bug-workaround kept the media in a loading state when
a read operation was pending, but didn't always transition back to
idle when the read operation was done. This CL fixes the problem
by making sure that we check the loading state after read callbacks.

These extra calls to check the loading state can in some cases cause
us to miss progress callbacks. We fix this by allowing in-flight
progress callbacks to complete even if reader_ has been destroyed.

BUG= 662615 

Review-Url: https://codereview.chromium.org/2481673004
Cr-Commit-Position: refs/heads/master@{#430860}
Commit  : a89cc8bcb5d204e3f42eb56d2db24837ba0d3a8a
Date    : Wed Nov 09 04:32:44 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev   N  Good?
chromium@430825  2.6273   0.318912  8  good
chromium@430850  2.77809  0.406218  8  good
chromium@430857  2.78108  0.610536  8  good
chromium@430859  2.61016  0.45576   8  good
chromium@430860  3.5695   0.704415  5  bad    <--
chromium@430863  3.52015  0.144894  5  bad
chromium@430875  3.54145  0.52724   5  bad
chromium@430924  3.64009  1.26917   8  bad

Bisect job ran on: android_nexus5_perf_bisect
Bug ID: 667484

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=video.html.src.crowd1080.ogv.canvas.true media.android.tough_video_cases
Test Metric: cpu_utilization/video.html?src_crowd1080.ogv_canvas_true
Relative Change: 38.55%

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus5_perf_bisect/builds/4363
Job details: https://chromeperf.appspot.com/buildbucket_job_status/8995348807671507728


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5325519522889728

| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Tests>AutoBisect.  Thank you!
Project Member

Comment 7 by 42576172...@developer.gserviceaccount.com, Nov 23 2016 


===== BISECT JOB RESULTS =====
Status: failed


=== Bisection aborted ===
The bisect was aborted because Bisect cannot identify a culprit: No values were found while testing the reference range.
Please contact the the team (see below) if you believe this is in error.

===== TESTED REVISIONS =====
Revision         Mean  Std Dev  N  Good?
chromium@430791  N/A   N/A      0  good
chromium@430986  N/A   N/A      0  bad

Bisect job ran on: android_nexus5_perf_bisect
Bug ID: 667484

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=crowd1080.ogv.gpu media.android.tough_video_cases
Test Metric: cpu_utilization/crowd1080.ogv_gpu
Relative Change: None

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus5_perf_bisect/builds/4373
Job details: https://chromeperf.appspot.com/buildbucket_job_status/8995269453541155712


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=6371502872592384

| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Tests>AutoBisect.  Thank you!
Project Member

Comment 8 by 42576172...@developer.gserviceaccount.com, Nov 23 2016 


===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : media: Make sure we transition back to a non-loading state
Author  : hubbe
Commit description:
  
An earilier bug-workaround kept the media in a loading state when
a read operation was pending, but didn't always transition back to
idle when the read operation was done. This CL fixes the problem
by making sure that we check the loading state after read callbacks.

These extra calls to check the loading state can in some cases cause
us to miss progress callbacks. We fix this by allowing in-flight
progress callbacks to complete even if reader_ has been destroyed.

BUG= 662615 

Review-Url: https://codereview.chromium.org/2481673004
Cr-Commit-Position: refs/heads/master@{#430860}
Commit  : a89cc8bcb5d204e3f42eb56d2db24837ba0d3a8a
Date    : Wed Nov 09 04:32:44 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev   N  Good?
chromium@430825  2.71371  0.404737  8  good
chromium@430850  2.68     0.42044   8  good
chromium@430857  2.77328  0.372739  8  good
chromium@430859  2.7727   0.467283  8  good
chromium@430860  3.88252  0.320388  5  bad    <--
chromium@430863  3.7776   0.763315  5  bad
chromium@430875  3.69766  0.480173  5  bad
chromium@430924  3.763    0.433311  5  bad

Bisect job ran on: android_nexus5_perf_bisect
Bug ID: 667484

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=video.html.src.crowd1080.ogv.canvas.true media.android.tough_video_cases
Test Metric: cpu_utilization/video.html?src_crowd1080.ogv_canvas_true
Relative Change: 38.67%

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus5_perf_bisect/builds/4374
Job details: https://chromeperf.appspot.com/buildbucket_job_status/8995269430086266800


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5892165832540160

| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Tests>AutoBisect.  Thank you!
Project Member

Comment 9 by 42576172...@developer.gserviceaccount.com, Nov 23 2016 


===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : media: Make sure we transition back to a non-loading state
Author  : hubbe
Commit description:
  
An earilier bug-workaround kept the media in a loading state when
a read operation was pending, but didn't always transition back to
idle when the read operation was done. This CL fixes the problem
by making sure that we check the loading state after read callbacks.

These extra calls to check the loading state can in some cases cause
us to miss progress callbacks. We fix this by allowing in-flight
progress callbacks to complete even if reader_ has been destroyed.

BUG= 662615 

Review-Url: https://codereview.chromium.org/2481673004
Cr-Commit-Position: refs/heads/master@{#430860}
Commit  : a89cc8bcb5d204e3f42eb56d2db24837ba0d3a8a
Date    : Wed Nov 09 04:32:44 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev   N  Good?
chromium@430825  2.46444  0.353501  8  good
chromium@430850  2.54318  0.287293  8  good
chromium@430857  2.55399  0.651468  8  good
chromium@430859  2.37238  0.239992  8  good
chromium@430860  3.11896  0.236529  5  bad    <--
chromium@430863  3.13138  0.545219  8  bad
chromium@430875  3.08255  0.273346  5  bad
chromium@430924  3.28445  1.07347   5  bad

Bisect job ran on: android_nexus5_perf_bisect
Bug ID: 667484

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=video.html.src.crowd1080.ogv media.android.tough_video_cases
Test Metric: cpu_utilization/video.html?src_crowd1080.ogv
Relative Change: 33.27%

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus5_perf_bisect/builds/4375
Job details: https://chromeperf.appspot.com/buildbucket_job_status/8995269422614121088


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=4627137607237632

| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Tests>AutoBisect.  Thank you!

Comment 10 by hubbe@chromium.org, Nov 23 2016 

I wonder if the extra UpdateLoadingState_Locked() calls is causing extra loading/not loading transitions?

Comment 11 by w...@chromium.org, Nov 23 2016 

It's surprising that would result in +35% cpu time over decoding though? It's only 2.5->3.1 so I don't know if we care that much.

Comment 12 by hubbe@chromium.org, Nov 23 2016 

These warnings are only on nexus 5, which seems kind of odd too.

Comment 13 by crouleau@chromium.org, Jan 13 2017

Status: Assigned (was: Untriaged)
Hubbe,

How do you know that they are only for Nexus 5?

Should be close this as WontFix?

Comment 14 by hubbe@chromium.org, Mar 1 2017

Status: WontFix (was: Assigned)
►

Sign in to add a comment