Issue metadata
Sign in to add a comment
|
34% regression in tracing.tracing_with_debug_overhead at 490928:491274 |
||||||||||||||||||||
Issue descriptionSee the link to graphs below.
,
Aug 11 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8971552791639028864
,
Aug 11 2017
=== BISECT JOB RESULTS === NO Perf regression found Bisect Details Configuration: win_8_perf_bisect Benchmark : tracing.tracing_with_debug_overhead Metric : trace_size_avg/http___www.amazon.com Revision Result N chromium@490927 10787755 +- 25301680 21 good chromium@491274 14403352 +- 41392359 21 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=http...www.amazon.com tracing.tracing_with_debug_overhead More information on addressing performance regressions: http://g.co/ChromePerformanceRegressions Debug information about this bisect: https://chromeperf.appspot.com/buildbucket_job_status/8971552791639028864 For feedback, file a bug with component Speed>Bisection
,
Sep 18 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8968081830539616480
,
Sep 18 2017
This benchmark has been turned down.
,
Sep 19 2017
=== Auto-CCing suspected CL author xunjieli@chromium.org === Hi xunjieli@chromium.org, the bisect results pointed to your CL, please take a look at the results. === BISECT JOB RESULTS === Perf regression found with culprit Suspected Commit Author : xunjieli Commit : 357e1deefca78c61e457f340270c9cd6f38321f5 Date : Thu Aug 03 22:16:30 2017 Subject: [wpr-go] Use a dummy cert if no cert is recorded Bisect Details Configuration: win_8_perf_bisect Benchmark : tracing.tracing_with_debug_overhead Metric : trace_size_avg/http___www.amazon.com Change : 60.19% | 10224601.4762 -> 16378818.8095 Revision Result N chromium@490844 10224601 +- 11610601 21 good chromium@491399 12852643 +- 18077268 6 good chromium@491676 14317237 +- 25245017 6 good chromium@491815 13523066 +- 22956329 6 good chromium@491884 13319445 +- 19952778 6 good chromium@491919 12858539 +- 24132060 14 good chromium@491924 10050616 +- 5233290 9 good chromium@491924,catapult@b0f1e24d46 11004978 +- 15416887 9 good chromium@491924,catapult@357e1deefc 12601905 +- 15170398 9 bad <-- chromium@491925 14752495 +- 32513438 9 bad chromium@491926 13907311 +- 24133007 9 bad chromium@491928 12057575 +- 14060395 14 bad chromium@491936 12893210 +- 19860183 14 bad chromium@491953 16378819 +- 55570720 21 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=http...www.amazon.com tracing.tracing_with_debug_overhead More information on addressing performance regressions: http://g.co/ChromePerformanceRegressions Debug information about this bisect: https://chromeperf.appspot.com/buildbucket_job_status/8968081830539616480 For feedback, file a bug with component Speed>Bisection
,
Sep 19 2017
Does "tracing.tracing_with_debug_overhead" measure the memory usage? We are using more memory with WPRGo.
,
Sep 19 2017
We may get 30% more trace events because they are emitted by network code that only exercised with WPRGO?
,
Nov 10 2017
Re#8: That's very possible. Let me archive this. I don't think it's worth digging deeper given that this is an infra change and not a real regression. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by 42576172...@developer.gserviceaccount.com
, Aug 11 2017