1686106 - Share gfxCharacterMap as attached to FontFace

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, enhancement)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

From bug 1683904 comment 2:

The gfxCharacterMaps, which are the potentially-large records attached to the FontFaces, could also be shared, although from a quick look at the code I don't think we're currently doing that -- which may be a potential memory saving we should implement.)

Comment 1

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1686106 - Allow the character map record created for unicode-range to be shared among FontFaces with the same descriptor. r?heycam

This will reduce memory footprint when there are multiple @font-face rules with the same unicode-range descriptor,
which is common when, for example, a site loads several styles of a family, all with the same character repertoire.

Comment 2

[Jonathan Kew [:jfkthame]]

Henrik, I'd expect this to significantly reduce the memory usage of unicode-range in cases like Google Docs where several related font faces, all having the same character coverage, are loaded. If you have a chance to test with it and compare your results, that'd be great.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Happy to do so. Can you trigger a try build for your changes? I would assume we would have to run tests anyway.

Comment 4

[Jonathan Kew [:jfkthame]]

Pushed a try run at https://treeherder.mozilla.org/jobs?repo=try&revision=69c7a63c5dfdd89740a46494ebbaf4d4ac4f96a2.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Is it expected that I see a single entry only now with even way lesser memory used under the once-reported list?

Once-reported {
  1 block in heap block record 275 of 36,364
  143,360 bytes (139,272 requested / 4,088 slop)
  0.04% of the heap (59.16% cumulative)
  0.04% of once-reported (66.80% cumulative)
  Allocated at {
    #01: nsTArray_Impl<gfxSparseBitSet::Block, nsTArrayInfallibleAllocator>::Compact() (/Users/henrik/code/gecko/Firefox Nightly.app/Contents/MacOS/XUL + 0xfa6d64)
    #02: mozilla::dom::FontFace::GetUnicodeRangeAsCharacterMap() (/Users/henrik/code/gecko/Firefox Nightly.app/Contents/MacOS/XUL + 0x2d3dc6b)
    #03: mozilla::dom::FontFaceSet::FindOrCreateUserFontEntryFromFontFace(nsTSubstring<char> const&, mozilla::dom::FontFace*, mozilla::StyleOrigin) (/Users/henrik/code/gecko/Firefox Nightly.app/Contents/MacOS/XUL + 0x2d426b2)
    #04: mozilla::dom::FontFace::CreateUserFontEntry() (/Users/henrik/code/gecko/Firefox Nightly.app/Contents/MacOS/XUL + 0x2d3d371)
    #05: mozilla::dom::FontFace::Load(mozilla::ErrorResult&) (/Users/henrik/code/gecko/Firefox Nightly.app/Contents/MacOS/XUL + 0x2d3d157)
    #06: mozilla::dom::FontFace_Binding::load_promiseWrapper(JSContext*, JS::Handle<JSObject*>, void*, JSJitMethodCallArgs const&) (/Users/henrik/code/gecko/Firefox Nightly.app/Contents/MacOS/XUL + 0x1bba99c)

I run the build only a couple of minutes but I assume that should be enough. But still wonder how this can change that much from more than 100MB to just some kB.

Comment 6

[Jonathan Kew [:jfkthame]]

It would depend very much on the workload. If the site you visit loads numerous font faces that all have the same unicode-range descriptor, previously we'd have allocated a separate character-map for each of these, whereas now they will all share the same record, so the impact could be quite large. If you cause a variety of different fonts to be used, particularly if they're for different scripts/languages, I would expect that there'd still be multiple allocations as they won't all share the same unicode-range (but the total number should still be greatly reduced from when each face had its own).

You might like to try accessing a few non-Latin fonts in GDocs (for example) and see how it looks then.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

So I opened a couple of huge Google docs, which include a good amount of Emojis, and that increased the memory of the Google specific process (Fission enabled) to about 1.4GB. But with the saved DMD report I was not able to see something different. It's just the single entry as mentioned in my last comment. Maybe we report entries somewhere else now, even not under heap-unclassified?

Comment 8

[Jonathan Kew [:jfkthame]]

That's interesting. With this patch, we share a common "pool" of gfxCharacterMap objects that may be referenced by gfxFontEntry and gfxFontFamily objects (that was already being done) and now by dom::FontFace objects as well, to represent their unicode-range. So on reflection, this is probably being "absorbed" into what is reported as font-charmaps in the verbose about:memory display.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Probably not. Even with the Google process taking up 1GB of memory I only see the follwoing in the verbose measurement:

17,920 B (00.00%) ── font-charmaps

Which is not a size that I would expect. Are user-fonts somewhat related?

├──────8,097,816 B (00.62%) -- gfx
│ ├──7,546,672 B (00.58%) -- user-fonts

Maybe you should have a look at that on your own, given that I don't know where to look at.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2bbc29a1d8f1
Allow the character map record created for unicode-range to be shared among FontFaces with the same descriptor. r=heycam

Comment 11

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/2bbc29a1d8f1

Comment 12

[Andra Esanu (needinfo me)]

== Change summary for alert #28420 (as of Thu, 14 Jan 2021 09:12:46 GMT) ==

Improvements:

Ratio	Suite	Test	Platform	Options	Absolute values (old vs new)
9%	Heap Unclassified		windows10-64-shippable-qr	tp6	64,965,155.58 -> 59,298,975.07
8%	Heap Unclassified		windows10-64-shippable-qr	tp6	63,985,347.30 -> 59,017,581.78

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=28420

Comment 13

[Florin Strugariu [:Bebe]]

== Change summary for alert #28475 (as of Mon, 18 Jan 2021 05:53:45 GMT) ==

Improvements:

Ratio	Suite	Test	Platform	Options	Absolute values (old vs new)
15%	fandom	ContentfulSpeedIndex	linux64-shippable	nocondprof warm	264.79 -> 224.42
11%	google-slides	FirstVisualChange	macosx1014-64-shippable-qr	nocondprof warm webrender	405.00 -> 360.00
10%	fandom	fcp	linux64-shippable-qr	nocondprof warm webrender	190.71 -> 171.17
9%	fandom	SpeedIndex	linux64-shippable	nocondprof warm	354.04 -> 321.83
7%	fandom		linux64-shippable-qr	nocondprof warm webrender	261.92 -> 242.52
7%	google-slides	fcp	linux64-shippable	nocondprof warm	194.71 -> 181.21
6%	google-slides	SpeedIndex	macosx1014-64-shippable-qr	nocondprof warm webrender	766.71 -> 721.00
6%	google-slides	ContentfulSpeedIndex	macosx1014-64-shippable-qr	nocondprof warm webrender	907.79 -> 857.50
5%	google-slides	PerceptualSpeedIndex	macosx1014-64-shippable-qr	nocondprof warm webrender	763.04 -> 721.33
5%	fandom	loadtime	linux64-shippable-qr	nocondprof warm webrender	367.96 -> 349.00
5%	google-docs	fcp	linux64-shippable-qr	nocondprof warm webrender	221.92 -> 210.79
4%	google-slides		linux64-shippable	nocondprof warm	441.36 -> 424.58
4%	google-slides		linux64-shippable	nocondprof warm	441.45 -> 425.08
3%	google-docs		linux64-shippable-qr	nocondprof warm webrender	402.45 -> 391.09
2%	youtube	ContentfulSpeedIndex	android-hw-g5-7-0-arm7-api-16-shippable	nocondprof warm webrender	530.50 -> 517.75

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=28475