Issue metadata
Sign in to add a comment
|
1%-152.3% regression in system_health.memory_desktop at 610733:610738 |
||||||||||||||||||||
Issue descriptionSee the link to graphs below.
,
Nov 26
đź“Ť Pinpoint job started. https://pinpoint-dot-chromeperf.appspot.com/job/130f2e67e40000
,
Nov 27
📍 Found significant differences after each of 2 commits. https://pinpoint-dot-chromeperf.appspot.com/job/130f2e67e40000 Apply morx if there's no GSUB! by behdad@behdad.org https://chromium.googlesource.com/external/github.com/harfbuzz/harfbuzz/+/14ff3cbe0f30dea24e1bb175b1e8e41039f6afdc memory:chrome:all_processes:reported_by_chrome:malloc:allocated_objects_size: 3.649e+08 → No values Roll HarfBuzz to 2.1.1 plus AAT fixes by drott@chromium.org https://chromium.googlesource.com/chromium/src/+/c67f53b0b70f33c47159d37f7e59bb44399b0d09 memory:chrome:all_processes:reported_by_chrome:malloc:allocated_objects_size: No values → 9.196e+08 Understanding performance regressions: http://g.co/ChromePerformanceRegressions Benchmark documentation link: https://bit.ly/system-health-benchmarks
,
Nov 27
I believe the memory increase are a consequence of moving allocations to HarfBuzz, while they were previously performed by CoreText - this is the nature of this change: Running AAT shaping inside HarfBuzz versus running it in CoreText. When AAT processing is performed in HarfBuzz, I assume the allocations are now traced, whereas they were previously hidden behind calling CoreText API. I'll look into what we can do about the Taobao performance decrease and see if we can improve things there. Overall, however, the HarfBuzz AAT shaping change brings about a 28.9% improvement from ~4.3 seconds down to 3 seconds for html5-full-render https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDQwOT61AoM - so we'd really like to keep this change. They also speed up the blink_perf.layout word-break-break-word benchmark by 16.3%. Separate measurements of pure shaping performance also bring improvements with system font rendering performance: Compare https://docs.google.com/spreadsheets/d/1aslvatqIBZpvDSnf59aDnwRLXKmJlrMbtSH_5itEaaQ/edit?usp=drive_web&ouid=101230465101683400358
,
Nov 29
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/023f5763fc17c435b386782af5b7217ebcb09b15 commit 023f5763fc17c435b386782af5b7217ebcb09b15 Author: Dominik Röttsches <drott@chromium.org> Date: Thu Nov 29 17:02:06 2018 Switch Mac OS HarfBuzz hb_face creation to table copying Removing the CTFont based construction when rolling to HarfBuzz' native AAT lead us to falling back to attempting the mmap'ed access to the font SkStreamAsset. However, the implementation for onOpenStream in SkTypeface_Mac is highly inefficient and synthesizes a font from copying all tables. Disable this type of instantiation on Mac and use the table copy method instead. This should address memory regression for the HarfBuzz AAT roll [1]. [1] https://chromium.googlesource.com/chromium/src/+/c67f53b0b70f33c47159d37f7e59bb44399b0d09 Bug: 908552 Change-Id: Ibf19ea6308f34fd4927e2b7fd59cdff20f3aad6d Tbr: eae@chromium.org, behdad@chromium.org Reviewed-on: https://chromium-review.googlesource.com/c/1355129 Reviewed-by: Dominik Röttsches <drott@chromium.org> Reviewed-by: Behdad Esfahbod <behdad@chromium.org> Reviewed-by: Ben Wagner <bungeman@chromium.org> Commit-Queue: Dominik Röttsches <drott@chromium.org> Cr-Commit-Position: refs/heads/master@{#612233} [modify] https://crrev.com/023f5763fc17c435b386782af5b7217ebcb09b15/third_party/blink/renderer/platform/fonts/shaping/harfbuzz_face.cc
,
Nov 30
These have all recovered. As much as I sometimes struggle with analysing performance results, this was a helpful warning. Thanks for sheriffing, miu@.
,
Nov 30
Issue 909099 has been merged into this issue.
,
Jan 17
(5 days ago)
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by 42576172...@developer.gserviceaccount.com
, Nov 26