Issue metadata
Sign in to add a comment
|
4.9% regression in system_health.common_desktop at 517943:518061 |
||||||||||||||||||||||
Issue descriptionSee the link to graphs below.
,
Nov 24 2017
๐ Pinpoint job started. https://pinpoint-dot-chromeperf.appspot.com/job/1061ef07f80000
,
Nov 24 2017
๐ Couldn't reproduce a difference. https://pinpoint-dot-chromeperf.appspot.com/job/1061ef07f80000
,
Jan 18 2018
๐ Pinpoint job started. https://pinpoint-dot-chromeperf.appspot.com/job/129d37d0840000
,
Jan 18 2018
Trying a wider bisect.
,
Jan 19 2018
๐ Found a significant difference after 1 commit. https://pinpoint-dot-chromeperf.appspot.com/job/129d37d0840000 [heap] Re-enable parallel marking By mlippautz@chromium.org ยท Mon Nov 20 13:03:03 2017 v8 @ a9cab08e6c38a11c370350fdc844e32c361179d9 Understanding performance regressions: http://g.co/ChromePerformanceRegressions
,
Jan 19 2018
Thanks for triaging. This is expected when we have a benchmark that triggers a full garbage collection that is not preceded by incremental or concurrent marking. In this case the parallel marker will take over and and we see a regression in CPU time. Since this blocks the main thread that is fine. (I observed this behavior locally on a few websites; unfortunately we don't have the V8 metrics in the trace file) |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by 42576172...@developer.gserviceaccount.com
, Nov 24 2017