Issue metadata
Sign in to add a comment
|
1.4%-159.4% regression in system_health.memory_desktop at 524735:525248 |
||||||||||||||||||||
Issue descriptionSee the link to graphs below.
,
Dec 21 2017
๐ Pinpoint job started. https://pinpoint-dot-chromeperf.appspot.com/job/12dbabc1040000
,
Dec 21 2017
๐ Found a significant difference after 1 commit. https://pinpoint-dot-chromeperf.appspot.com/job/12dbabc1040000 SetResource() in ResourceFetcher for FontResources By japhet@chromium.org ยท Mon Dec 18 21:42:32 2017 chromium @ a1bfc9f9cb531a1d5dd1e28b51a38b728ece1235 Understanding performance regressions: http://g.co/ChromePerformanceRegressions
,
Jan 23 2018
japhet: this is a pretty huge memory regression; the bisect is repro-ing 100MiB increase. Here are the traces it spit out, click the (M) in the upper right for a full memory dump: Before your CL: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/browse_news_nytimes_2017-12-21_14-53-35_6934.html After your CL: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/browse_news_nytimes_2017-12-21_15-00-34_32369.html You can see in the attached screenshot that after your CL, we use a lot more memory in malloc in the renderer process (skia->sk_glyph_cache) cc-ing desktop and android memory benchmark owners.
,
Jan 23 2018
Sorry, I apparently didn't include this bug in my fix. https://chromium-review.googlesource.com/c/chromium/src/+/848014 partially reverted the offending CL and landed as r527372. The graphs on https://chromeperf.appspot.com/group_report?bug_id=797060 appears to show full recovery of all regressions around r527372, so I think this is fixed. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by 42576172...@developer.gserviceaccount.com
, Dec 21 2017