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

Issue 641150 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 645594
Owner:
Last visit 27 days ago
Closed: Sep 2016
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

74.5% regression in performance_browser_tests at 414129:414194

Project Member Reported by pras...@chromium.org, Aug 25 2016

Issue description

See the link to graphs below.
 
All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=641150

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


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

chromium-rel-win7-dual
Project Member

Comment 3 by 42576172...@developer.gserviceaccount.com, Aug 26 2016


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


=== Bisection aborted ===
The bisect was aborted because The metric values for the initial "good" and "bad" revisions do not represent a clear regression.
Please contact the the team (see below) if you believe this is in error.

=== Warnings ===
The following warnings were raised by the bisect job:

 * Bisect failed to reproduce the regression with enough confidence.

===== TESTED REVISIONS =====
Revision         Mean     Std Dev   N   Good?
chromium@414128  2.04579  0.301656  18  good
chromium@414194  2.15796  0.158887  18  bad

Bisect job ran on: win_perf_bisect
Bug ID: 641150

Test Command: .\src\out\Release\performance_browser_tests.exe --test-launcher-print-test-stdio=always --enable-gpu
Test Metric: CastV2Performance_gpu_60fps/video_jitter
Relative Change: 0.30%
Score: 0

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/win_perf_bisect/builds/6882
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9003317229287297072


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

| 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!
Trying more bisects.
Project Member

Comment 7 by 42576172...@developer.gserviceaccount.com, Sep 24 2016

Mergedinto: 645594
Status: Duplicate (was: Assigned)

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


===== SUSPECTED CL(s) =====
Subject : Use vsync manager regardless of begin frame settings
Author  : enne
Commit description:
  
There was some hope that the ui::CompositorVSyncManager could be removed
once --enable-begin-frame-scheduling was turned on.  Unfortunately, the
vsync manager is used by two additional systems that can't be easily
removed: DelegatedFrameHost::AttemptFrameSubscriberCapture as well as
components/exo/wayland/server.cc.  The latter may go away eventually.
If so, then the frame capture could then be changed to more simple
polling as needed instead of vsync manager and observer system that
needs to be plumbed everywhere.

In the medium term, the vsync manager needs to live on in all paths.
This means that BrowserCompositorOutputSurface and ui::Compositor always
need to update the vsync manager with changes.  Conditionals for
whether or not to send vsync information to renderers just get moved
down the pipeline from the output surface to DelegatedFrameHost.

Review-Url: https://codereview.chromium.org/2277883002
Cr-Commit-Position: refs/heads/master@{#414186}
Commit  : 0875b32a9ef74d66951b77930ca46f1a3bf08043
Date    : Wed Aug 24 23:00:35 2016


===== TESTED REVISIONS =====
Revision         Mean      Std Dev    N   Good?
chromium@414166  0.29948   0.056412   5   good
chromium@414178  0.259066  0.0700362  5   good
chromium@414184  0.255061  0.0983861  12  good
chromium@414185  0.287108  0.146424   12  good
chromium@414186  0.500494  0.0714385  8   bad    <--
chromium@414187  0.648414  0.0894937  5   bad
chromium@414190  0.553216  0.0427024  5   bad
chromium@414214  0.556507  0.12728    5   bad

Bisect job ran on: win_x64_perf_bisect
Bug ID: 641150

Test Command: .\src\out\Release_x64\performance_browser_tests.exe --test-launcher-print-test-stdio=always --enable-gpu
Test Metric: CastV2Performance_gpu_30fps_slow/video_jitter
Relative Change: 85.82%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/win_x64_perf_bisect/builds/1479
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9000698273665473152


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

| 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, Sep 24 2016


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


===== SUSPECTED CL(s) =====
Subject : Use vsync manager regardless of begin frame settings
Author  : enne
Commit description:
  
There was some hope that the ui::CompositorVSyncManager could be removed
once --enable-begin-frame-scheduling was turned on.  Unfortunately, the
vsync manager is used by two additional systems that can't be easily
removed: DelegatedFrameHost::AttemptFrameSubscriberCapture as well as
components/exo/wayland/server.cc.  The latter may go away eventually.
If so, then the frame capture could then be changed to more simple
polling as needed instead of vsync manager and observer system that
needs to be plumbed everywhere.

In the medium term, the vsync manager needs to live on in all paths.
This means that BrowserCompositorOutputSurface and ui::Compositor always
need to update the vsync manager with changes.  Conditionals for
whether or not to send vsync information to renderers just get moved
down the pipeline from the output surface to DelegatedFrameHost.

Review-Url: https://codereview.chromium.org/2277883002
Cr-Commit-Position: refs/heads/master@{#414186}
Commit  : 0875b32a9ef74d66951b77930ca46f1a3bf08043
Date    : Wed Aug 24 23:00:35 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev    N   Good?
chromium@414128  2.1776   0.237094   27  good
chromium@414161  2.12387  0.311651   41  good
chromium@414178  2.06208  0.371862   41  good
chromium@414182  2.26774  0.101416   8   good
chromium@414184  2.27574  0.128494   8   good
chromium@414185  2.19551  0.0512189  5   good
chromium@414186  1.95462  0.375685   18  bad    <--
chromium@414194  1.95307  0.373907   27  bad

Bisect job ran on: win_perf_bisect
Bug ID: 641150

Test Command: .\src\out\Release\performance_browser_tests.exe --test-launcher-print-test-stdio=always --enable-gpu
Test Metric: CastV2Performance_gpu_60fps/video_jitter
Relative Change: 25.73%
Score: 99.5

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/win_perf_bisect/builds/6941
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9000698278433058224


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

| 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!

Sign in to add a comment