Issue metadata
Sign in to add a comment
|
2%-17.4% regression in media.tough_video_cases_tbmv2 at 476227:476344 |
||||||||||||||||||||
Issue descriptionLikely a duplicate of Issue 729630 , but the perf dashboard is not updating that issue as I link additional alerts. So filing a separate issue to ensure we get a bisect. Duplicates will work out naturally when the bisect blames the common CL Uptick in - size-in-bytes for allocated objects metrics - on win7 video tests.
,
Jun 5 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8977601502237780848
,
Jun 5 2017
=== BISECT JOB RESULTS === Perf regression found with culprit Suspected Commit Author : Reilly Grant Commit : 64bff37c24aefed6abfc5066f8ff5c49e71072f7 Date : Thu Jun 01 13:31:01 2017 Subject: Ship WebUSB Bisect Details Configuration: win_perf_bisect Benchmark : media.tough_video_cases_tbmv2 Metric : memory:chrome:renderer_processes:reported_by_chrome:v8:heap:old_space:effective_size_avg/video.html?src_tulip2.wav_type_audio Change : 39.63% | 1323008.0 -> 1847296.0 Revision Result N chromium@476238 1323008 +- 0.0 6 good chromium@476265 1323008 +- 0.0 6 good chromium@476266 1323008 +- 0.0 6 good chromium@476267 1847296 +- 0.0 6 bad <-- chromium@476269 1847296 +- 0.0 6 bad chromium@476272 1847296 +- 0.0 6 bad chromium@476278 1847296 +- 0.0 6 bad chromium@476291 1847296 +- 0.0 6 bad chromium@476344 1847296 +- 0.0 6 bad To Run This Test src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=video.html.src.tulip2.wav.type.audio media.tough_video_cases_tbmv2 Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8977601502237780848 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=4867657980968960 | 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 Speed>Bisection. Thank you!
,
Jun 8 2017
I've run this test locally and cannot reproduce this result by either reverting the patch above or flipping WebUSB from stable to experimental. ToT (WebUSB stable): https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_0-2017-06-07_18-18-09-87798.html ToT with WebUSB experimental: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_0-2017-06-08_10-24-00-53536.html ToT with patch reverted: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_0-2017-06-08_11-07-18-76634.html The result in all cases is that memory:chrome:renderer_processes:reported_by_chrome:v8:heap:old_space:effective_size is 2,560.0 KiB. Note, this is different from the results above and I cannot explain that.
,
Jun 9 2017
Where in the traces should I be looking for effective size? (Sorry, haven't used these much). I don't know much about WebUSB - not sure how it may be having some effect. These tests are definitely not calling that API. I do see that a number of different regressions seem to be blaming your CL, which adds some confidence that there may be an issue. Though its weird that a total revert didn't have any effect on the value. I'll start another bisect with a starting point that is ~20 revisions before your CL - if its before you we should see it. https://chromeperf.appspot.com/buildbucket_job_status/8977230854554565536 |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by chcunningham@google.com
, Jun 5 2017