1458649 - gfxPlatformFontList::InitFontList takes a long time during the content process startup

Status: RESOLVED WORKSFORME

(Core :: Graphics: Text, enhancement, P3)

Description

[:Felipe Gomes (needinfo for replies!)]

As seen on this profile: https://perfht.ml/2wb32uM

gfxPlatform::Init() took a significant part of the content process startup. In this case, it was 57ms, split as:

45ms in gfxPlatformGtk::CreatePlatformFontList
          gfxPlatformFontList::InitFontList

11ms in gfxFcPlatformFontList::GetFTLibrary

 1ms in gfxPlatform::CreateCMSOutputProfile

Is this information that was already retrieved by the parent process, and could just be sent to the child process? If yes, it looks like it'd be a big saving if every child process starting up could avoid this cost.

Comment 1

[:Felipe Gomes (needinfo for replies!)]

Hey Jonathan, what do you think about this? Do you have a sense of how often this affects users, and if this is linux-only or a similar prob can happen on other platforms?

Comment 2

[Jonathan Kew [:jfkthame]]

It's unlikely to be a cross-platform issue, as the font list setup is quite different on each.

On Linux, InitFontList() already uses information passed from the parent. Of the gfxPlatformFontList::InitFontList time in the profile, 44ms is spent in FcNameParse, so that's the time it takes to deserialize the patterns sent by the parent process back to FcPattern objects.

I suppose in principle we could defer that parsing, and just save the serialized patterns in the font entries; we'd then deserialize them on-demand when we need to use any particular font. There'd be some added complexity, and we'd pay the cost later when first trying to use the font, but we could probably take a substantial amount of that 44ms out of the startup path.

Comment 3

[:Felipe Gomes (needinfo for replies!)]

Ok, so not a P1 right now, but this might become more important soon in light of Project Fission where we might be spawning a lot more processes for out-of-process iframes. If this info about fonts can be lazy-loaded (and, in practice, not loaded for the majority of the cases) it sounds like a big win.

An alternative to the serialization/deserialization could be shared memory, right?

Comment 4

[Florian Quèze [:florian]]

Is this bug still relevant?

Comment 5

[Jonathan Kew [:jfkthame]]

I think we should close this as WFM.... the shared-memory font list has extensively revised how things work here, and should make (the font-related aspects of) content-process startup very cheap.

If we see a problem with a current version of Gecko, we should treat it as a new, unrelated issue, given that what the profile here was showing is no longer part of the picture.