Issue metadata
Sign in to add a comment
|
A zero-to-nonzero regression in thread_times.simple_mobile_sites at 426910:426987 |
||||||||||||||||||||
Issue descriptionSee the link to graphs below.
,
Nov 2 2016
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8997109633166444496
,
Nov 2 2016
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8997109588126753344
,
Nov 2 2016
=== Auto-CCing suspected CL author danakj@chromium.org === Hi danakj@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 : cc: Add back a benchmark category trace for counting renderer frames Author : danakj Commit description: When deleting DelegatingRenderer::SwapBuffers I failed to notice that the TRACE_EVENT in there had the benchmark category. This category is used by perf tests, and without that event they had no way to count the number of renderer frames produced. This adds benchmark to the DrawLayers trace event in LayerTreeHostImpl instead and points the perf tests at that. Also removes the benchmark category from the GLRenderer and SoftwareRenderer classes as they are never used in the renderer and are not used for perf tests (tools/ no longer refers to the name "SwapBuffers" for perf tests). R=enne@chromium.org TBR=dtu BUG= 656947 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel Review-Url: https://chromiumcodereview.appspot.com/2442453003 Cr-Commit-Position: refs/heads/master@{#426952} Commit : 7607802c76a4a0b826d22807213e981025ec734b Date : Sat Oct 22 02:26:00 2016 ===== TESTED REVISIONS ===== Revision Mean Std Dev N Good? chromium@426937 0.0 0.0 5 good chromium@426946 0.0 0.0 5 good chromium@426950 0.0 0.0 5 good chromium@426951 0.0 0.0 5 good chromium@426952 2.20074 0.0210644 5 bad <-- chromium@426954 2.17229 0.0265345 5 bad Bisect job ran on: android_nexus5_perf_bisect Bug ID: 661523 Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests thread_times.key_mobile_sites_smooth Test Metric: thread_renderer_compositor_cpu_time_per_frame/thread_renderer_compositor_cpu_time_per_frame Relative Change: Zero to non-zero Score: 99.9 Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus5_perf_bisect/builds/4313 Job details: https://chromeperf.appspot.com/buildbucket_job_status/8997109633166444496 Not what you expected? We'll investigate and get back to you! https://chromeperf.appspot.com/bad_bisect?try_job_id=5546601169289216 | 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!
,
Nov 2 2016
ok the commit message explains everything.
,
Nov 2 2016
===== BISECT JOB RESULTS ===== Status: completed ===== SUSPECTED CL(s) ===== Subject : cc: Add back a benchmark category trace for counting renderer frames Author : danakj Commit description: When deleting DelegatingRenderer::SwapBuffers I failed to notice that the TRACE_EVENT in there had the benchmark category. This category is used by perf tests, and without that event they had no way to count the number of renderer frames produced. This adds benchmark to the DrawLayers trace event in LayerTreeHostImpl instead and points the perf tests at that. Also removes the benchmark category from the GLRenderer and SoftwareRenderer classes as they are never used in the renderer and are not used for perf tests (tools/ no longer refers to the name "SwapBuffers" for perf tests). R=enne@chromium.org TBR=dtu BUG= 656947 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel Review-Url: https://chromiumcodereview.appspot.com/2442453003 Cr-Commit-Position: refs/heads/master@{#426952} Commit : 7607802c76a4a0b826d22807213e981025ec734b Date : Sat Oct 22 02:26:00 2016 ===== TESTED REVISIONS ===== Revision Mean Std Dev N Good? chromium@426937 0.0 0.0 5 good chromium@426950 0.0 0.0 5 good chromium@426951 0.0 0.0 5 good chromium@426952 5.6663 0.118397 5 bad <-- chromium@426953 5.71261 0.252634 5 bad chromium@426956 5.71032 0.0919683 5 bad chromium@426962 5.57613 0.095446 5 bad chromium@426987 5.47176 0.0799473 5 bad Bisect job ran on: android_nexus5_perf_bisect Bug ID: 661523 Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests thread_times.key_mobile_sites_smooth Test Metric: thread_renderer_main_cpu_time_per_frame/thread_renderer_main_cpu_time_per_frame Relative Change: Zero to non-zero Score: 99.9 Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus5_perf_bisect/builds/4314 Job details: https://chromeperf.appspot.com/buildbucket_job_status/8997109588126753344 Not what you expected? We'll investigate and get back to you! https://chromeperf.appspot.com/bad_bisect?try_job_id=6125087562924032 | 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 |
|||||||||||||||||||||
Comment 1 by primiano@chromium.org
, Nov 2 2016