Issue metadata
Sign in to add a comment
|
1%-11.2% regression in v8.infinite_scroll at 403611:403611 |
||||||||||||||||||||
Issue descriptionSee the link to graphs below.
,
Jul 7 2016
No ref build, but there is a consistent increase across different platforms.
,
Jul 7 2016
===== BISECT JOB RESULTS ===== Status: completed ===== TESTED REVISIONS ===== Revision Mean Std Dev N Good? chromium@403610 6048230 14821.1 5 good chromium@403610,v8@b1063f7a41 6046546 6794.11 5 good chromium@403610,v8@6f920d7d59 6042686 3947.26 5 good chromium@403610,v8@5927deaaf1 6043829 1043.27 5 good chromium@403610,v8@317dc0578f 6051042 13641.7 5 good chromium@403610,v8@486d181928 6046075 16449.1 5 good chromium@403610,v8@de5beb45b8 6044160 881.689 5 good chromium@403611 6096176 15731.8 5 bad Bisect job ran on: linux_perf_bisect Bug ID: 625894 Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --also-run-disabled-tests top_10_mobile_memory Test Metric: memory:chrome:all_processes:reported_by_chrome:v8:allocated_objects_size_max/https___mobile.twitter.com_justinbieber?skip_interstitial_true Relative Change: 0.79% Score: 0 Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/linux_perf_bisect/builds/6577 Job details: https://chromeperf.appspot.com/buildbucket_job_status/9007832599226486752 Not what you expected? We'll investigate and get back to you! https://chromeperf.appspot.com/bad_bisect?try_job_id=5882958880178176 | 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!
,
Jul 15 2016
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/9007039033249631616
,
Jul 15 2016
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/9007038987786111904
,
Jul 15 2016
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/9007038978180887120
,
Jul 16 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@403610 8803286 516179 12 good chromium@403611 7970078 503637 18 bad Bisect job ran on: android_nexus5X_perf_bisect Bug ID: 625894 Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests top_10_mobile_memory Test Metric: memory:chrome:all_processes:reported_by_chrome:v8:allocated_objects_size_max/http___en.m.wikipedia.org_wiki_Science Relative Change: 11.18% Score: 0 Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus5X_perf_bisect/builds/345 Job details: https://chromeperf.appspot.com/buildbucket_job_status/9007038978180887120 Not what you expected? We'll investigate and get back to you! https://chromeperf.appspot.com/bad_bisect?try_job_id=5791307885182976 | 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!
,
Jul 16 2016
=== Auto-CCing suspected CL author ishell@chromium.org === Hi ishell@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 : [ic] Use UnseededNumberDictionary as a storage for names in TypeFeedbackMetadata. Author : ishell Commit description: The serializer does not support serialization of HashTables in general because after deserialization it might be necessary to rehash the table. However the UnseededNumberDictionary does not require rehashing and this CL allows them to be serialized. This CL also changes the shape of UnseededNumberDictionary: the details field is no longer part of the entry since no one needs it. BUG=chromium:576312, chromium:623516 Review-Url: https://codereview.chromium.org/2102073002 Cr-Commit-Position: refs/heads/master@{#37336} Commit : 70318619905dd1a10ac0f063da19cebf6d385ba0 Date : Tue Jun 28 16:16:12 2016 ===== TESTED REVISIONS ===== Revision Mean Std Dev N Good? chromium@403610 7416822 6647.9 5 good chromium@403610,v8@6b63d524c2 7431656 6300.57 5 good chromium@403610,v8@61c137c811 7431268 5993.36 5 good chromium@403610,v8@7031861990 7478584 4428.55 5 bad <-- chromium@403610,v8@efa7095e3e 7484465 9155.49 5 bad chromium@403610,v8@588e15c034 7486138 3181.55 5 bad chromium@403610,v8@b1063f7a41 7488534 6977.38 5 bad chromium@403611 7480523 5463.36 5 bad Bisect job ran on: win_perf_bisect Bug ID: 625894 Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --also-run-disabled-tests top_10_mobile_memory Test Metric: memory:chrome:all_processes:reported_by_chrome:v8:allocated_objects_size_max/http___search.yahoo.com_search;_ylt_?p_google Relative Change: 0.86% Score: 99.9 Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/win_perf_bisect/builds/6703 Job details: https://chromeperf.appspot.com/buildbucket_job_status/9007039033249631616 Not what you expected? We'll investigate and get back to you! https://chromeperf.appspot.com/bad_bisect?try_job_id=5812157803921408 | 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!
,
Jul 16 2016
===== BISECT JOB RESULTS ===== Status: completed ===== SUSPECTED CL(s) ===== Subject : [ic] Use UnseededNumberDictionary as a storage for names in TypeFeedbackMetadata. Author : ishell Commit description: The serializer does not support serialization of HashTables in general because after deserialization it might be necessary to rehash the table. However the UnseededNumberDictionary does not require rehashing and this CL allows them to be serialized. This CL also changes the shape of UnseededNumberDictionary: the details field is no longer part of the entry since no one needs it. BUG=chromium:576312, chromium:623516 Review-Url: https://codereview.chromium.org/2102073002 Cr-Commit-Position: refs/heads/master@{#37336} Commit : 70318619905dd1a10ac0f063da19cebf6d385ba0 Date : Tue Jun 28 16:16:12 2016 ===== TESTED REVISIONS ===== Revision Mean Std Dev N Good? chromium@403610 4684076 3709.97 5 good chromium@403610,v8@6b63d524c2 4695411 6151.19 5 good chromium@403610,v8@61c137c811 4695162 4351.44 5 good chromium@403610,v8@7031861990 4731054 3079.17 5 bad <-- chromium@403610,v8@efa7095e3e 4730736 3562.03 5 bad chromium@403610,v8@588e15c034 4731628 3128.65 5 bad chromium@403610,v8@b1063f7a41 4731534 4322.05 5 bad chromium@403611 4731834 6136.24 5 bad Bisect job ran on: android_nexus5X_perf_bisect Bug ID: 625894 Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests top_10_mobile_memory Test Metric: memory:chrome:all_processes:reported_by_chrome:v8:effective_size_max/https___mobile.twitter.com_justinbieber?skip_interstitial_true Relative Change: 1.02% Score: 99.9 Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus5X_perf_bisect/builds/344 Job details: https://chromeperf.appspot.com/buildbucket_job_status/9007038987786111904 Not what you expected? We'll investigate and get back to you! https://chromeperf.appspot.com/bad_bisect?try_job_id=5160263322435584 | 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!
,
Jul 22 2016
The numbers look odd to me, but the bisect bot seems to have high confidence. ishell, any idea what's going on here?
,
Jul 22 2016
Wait, I was looking at the wrong thing. This change does seem to cause the regression. ishell please investigate :)
,
Jul 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/2fec36d9adba268c148c3ab28b8ab412021a82f3 commit 2fec36d9adba268c148c3ab28b8ab412021a82f3 Author: ishell <ishell@chromium.org> Date: Tue Jul 26 11:58:26 2016 [ic] Avoid memory wasting when allocating names table of type feedback metadata. BUG= chromium:625894 Review-Url: https://codereview.chromium.org/2181303002 Cr-Commit-Position: refs/heads/master@{#38047} [modify] https://crrev.com/2fec36d9adba268c148c3ab28b8ab412021a82f3/src/objects.cc [modify] https://crrev.com/2fec36d9adba268c148c3ab28b8ab412021a82f3/src/objects.h [modify] https://crrev.com/2fec36d9adba268c148c3ab28b8ab412021a82f3/src/type-feedback-vector.cc
,
Jul 26 2016
Let's see if #12 will help or not.
,
Aug 5 2016
ishell: I don't see the numbers coming back down from #12
,
Aug 18 2016
Perf sheriff ping: reminder to follow up on possible performance issues
,
Oct 5 2016
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/c56222c9bd279c8a94697e21ed8ce1e0813c6347 commit c56222c9bd279c8a94697e21ed8ce1e0813c6347 Author: ishell <ishell@chromium.org> Date: Wed Oct 05 17:55:26 2016 [ic] Avoid feedback metadata names table reallocations. An attempt to fix memory regression (r38047) caused another regression because custom capacity chosen for names dictionary implied reallocations during initialization in some cases. BUG= chromium:625894 , chromium:632231 Review-Url: https://codereview.chromium.org/2394873002 Cr-Commit-Position: refs/heads/master@{#40006} [modify] https://crrev.com/c56222c9bd279c8a94697e21ed8ce1e0813c6347/src/type-feedback-vector.cc
,
Oct 10 2016
Update: I don't think I'm seeing a recovery in the graphs (https://chromeperf.appspot.com/group_report?bug_id=625894) In the past 4 days. Is there anything else that might be tried?
,
Oct 11 2016
We didn't get the new data yet: the latest results correspond to the beginning of September.
,
Nov 24 2016
I don't see much data after the beginning of September. What's going on? How can we verify that this is fixed?
,
Nov 30 2016
We dropped top_10_mobile_memory upstream a while ago (in favour of system_health.memory_mobile) and we are in the process of doing the same downstream. I am sorry but we can't do analysis on 6 months old bugs. Realistically, whatever the cause of this regression was it has been taken and is now "a feature" of chrome.
,
Dec 6 2016
Alright, sounds like this should be marked WontFix; sullivan@, does that sound right?
,
Dec 7 2016
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by qyears...@chromium.org
, Jul 5 2016