Issue metadata
Sign in to add a comment
|
1.1%-77.4% regression in memory.top_10_mobile at 483638:483901 |
||||||||||||||||||||
Issue descriptionProbably more fallout from "[heap] Allow a minimum semi-space size of 512K."
,
Jul 4 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8975007673647089216
,
Jul 4 2017
=== Auto-CCing suspected CL author cbruni@chromium.org === Hi cbruni@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 : Camillo Bruni Commit : bbc89774a6cbacd021f44f65eb0ea0f79f17b8f9 Date : Fri Jun 30 09:30:17 2017 Subject: [runtime] Enable double-lazy boilerplate creation again Bisect Details Configuration: android_nexus6_perf_bisect Benchmark : v8.mobile_infinite_scroll_tbmv2 Metric : v8-gc-incremental-step_max/flickr Change : 55.52% | 2.98566666667 -> 4.64333333333 Revision Result N chromium@483714 2.98567 +- 1.44338 6 good chromium@483729 2.61864 +- 1.86695 14 good chromium@483729,v8@eeeae375b9 2.43267 +- 0.459099 9 good chromium@483729,v8@bbc89774a6 3.45295 +- 4.14657 21 bad <-- chromium@483729,v8@6407a3c052 4.16443 +- 2.45717 14 bad chromium@483729,v8@ca93156294 3.65467 +- 0.315733 6 bad chromium@483730 4.75917 +- 1.4045 6 bad chromium@483731 5.4295 +- 0.394491 6 bad chromium@483733 4.7465 +- 1.34084 6 bad chromium@483737 4.9395 +- 2.01541 6 bad chromium@483744 4.64978 +- 2.31525 9 bad chromium@483773 4.64333 +- 1.51725 6 bad To Run This Test src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=flickr v8.mobile_infinite_scroll_tbmv2 More information on addressing performance regressions: http://g.co/ChromePerformanceRegressions Debug information about this bisect: https://chromeperf.appspot.com/buildbucket_job_status/8975007673647089216 For feedback, file a bug with component Speed>Bisection
,
Jul 5 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8974921206720499424
,
Jul 6 2017
=== Auto-CCing suspected CL author marja@chromium.org === Hi marja@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 : Marja Hölttä Commit : 937b5011b88e995658c5e08e48d9ab928cfe5eee Date : Fri Jun 30 11:12:52 2017 Subject: [parser] Skipping inner funcs: Associate data to SharedFunctionInfo, not Script. Bisect Details Configuration: android_webview_nexus6_aosp_perf_bisect Benchmark : system_health.memory_mobile Metric : memory:webview:all_processes:reported_by_chrome:v8:effective_size_avg/load_social/load_social_twitter Revision Result N chromium@483637 3092701 +- 92.376 6 good chromium@483686 3124931 +- 183234 6 good chromium@483711 3191943 +- 245984 6 good chromium@483723 3094270 +- 15154.8 6 good chromium@483729 3161246 +- 227514 6 good chromium@483729,v8@6407a3c052 3285989 +- 81.0761 6 good chromium@483729,v8@27b0d6a9fc 3286041 +- 301.552 6 good chromium@483729,v8@937b5011b8 3294563 +- 408.212 6 bad <-- chromium@483729,v8@ca93156294 3294486 +- 367.206 6 bad chromium@483730 3337269 +- 15326.2 6 bad chromium@483731 3337251 +- 14989.7 6 bad chromium@483732 3337220 +- 15024.3 6 bad chromium@483735 3337263 +- 14975.9 6 bad Please refer to the following doc on diagnosing memory regressions: https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/memory_benchmarks.md To Run This Test src/tools/perf/run_benchmark -v --browser=android-webview --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=load.social.twitter system_health.memory_mobile More information on addressing performance regressions: http://g.co/ChromePerformanceRegressions Debug information about this bisect: https://chromeperf.appspot.com/buildbucket_job_status/8974921206720499424 For feedback, file a bug with component Speed>Bisection
,
Jul 19 2017
These are expected regressions since my CL partially reverted a previous CL which was overly aggressive in saving memory but tanked performance. The long-term fix is to start collecting elements transitions for array literals immediately but still create AllocationSites lazily.
,
Jul 20 2017
,
Jul 24 2017
Issue 747843 has been merged into this issue. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by rmcilroy@chromium.org
, Jul 4 2017