Issue metadata
Sign in to add a comment
|
10.2%-56.2% regression in blink_perf.shadow_dom at 533538:533655 |
||||||||||||||||||
Issue descriptionSee the link to graphs below.
,
Feb 6 2018
📍 Pinpoint job started. https://pinpoint-dot-chromeperf.appspot.com/job/14c70429840000
,
Feb 6 2018
📍 Found a significant difference after 1 commit. https://pinpoint-dot-chromeperf.appspot.com/job/14c70429840000 Oilpan: Remove Coalesce() logic. by hpayer@chromium.org chromium @ fa293678b3eceaa1ed646ada4865bb875926aef6 Understanding performance regressions: http://g.co/ChromePerformanceRegressions
,
Feb 7 2018
Hmm. This looks like a real regression. Hannes: Would you mind taking a look?
,
Feb 20 2018
Yes, will take a look ASAP.
,
Mar 13 2018
Hannes: Any update on this? This looks like a real regression.
,
Mar 23 2018
This regressions is already open too long. I would close it with won't fix. This was the only regression visible on micro-benchmarks that triggered the old coalescing logic. The benefit of the change is simpler GC logic and less real-world jank. Improvements on other perf bots of the regression range: https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICQ7IOxgAgM https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICQ9IXEogkM The alternative is to revert this change and/or implement coalescing during idle time but I do not think it is worth the effort. kentaro WDYT?
,
Mar 23 2018
Issue 809445 has been merged into this issue.
,
Mar 23 2018
Fair enough :) The coalescing would make sense only when we implement StackHeapVector / StackHeapHashTable (then many backing stores will be released promptly). We don't have a plan to do this now.
,
Mar 27 2018
,
Mar 27 2018
,
Mar 27 2018
OK, I am closing this one for now. I am pretty happy with the removed jank on UMA.
,
Jun 27 2018
|
|||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||
Comment 1 by 42576172...@developer.gserviceaccount.com
, Feb 6 2018