699331 - Investigate name enumeration time at startup

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[John Daggett (:jtd)]

Telemetry numbers seem to indicate that a fair number of calls to InitOtherFamilyNames() and InitFaceNameLists() take a significant amount of time.

Telemetry data:
http://people.mozilla.org/~xstevens/telemetry/histogram-aggs-20111030.sorted.txt

Need to analyze the numbers for FONTLIST_INITOTHERFAMILYNAMES and FONTLIST_INITFACENAMELISTS.

See other comments in bug 600713.

Comment 1

[Vladan Djeric (:vladan)]

Attachment: Hangs in gfxFontFamily::ReadFaceNames()

I looked through Nightly 22 chrome-hang data from two weeks in March and I found that font operations are the second most common cause of multi-second main thread hangs after plugins.

I've attached the top chrome hang stacks relevant to this bug. If I'm interpreting these stacks correctly, it's mostly a case of a lot of disk I/O being done on the main thread. Can we do anything about these?

Comment 2

[Jonathan Kew [:jfkthame]]

In some cases this is triggered by the use of @font-face with src:local, which causes us to load all the names so that we can correctly implement the font name matching. Maybe instead of blocking on the name-loading, we should fall back to the next in the font-family list, and then refresh once the font names are available, like we do with downloadable fonts.

In other cases, it seems to be caused by the font info loader that we run shortly after startup. This is intended to preload font name and cmap info so that we -won't- block on these things when we actually need to use the fonts. But if disk access is slow (contention with other i/o?) and/or font files are large, maybe loading the info for one group of fonts is taking too long.

One thing we can try here is to read info for fewer fonts at a time, so that we return to the main event loop more frequently. Note that the code currently operates in "slices" of 10, but that actually represents 10 font -families-, which may be 40 individual faces (or even more, in the case of DirectWrite).

The first patch here simply moves the constants that control the font-loader into prefs, so that we (or QA, or users) can more easily adjust them to tune the behavior; and then the second patch adjusts them to read the fonts in smaller "slices"; I suggest we try this and see if it has any visible effect on the frequency of these hangs.

Comment 3

[Jonathan Kew [:jfkthame]]

Attachment: pt 1 - replace hardcoded font-loader constants with prefs to allow easier tuning

Comment 4

[Jonathan Kew [:jfkthame]]

Attachment: pt 2 - read info for fewer families each time the font-loader runs

Comment 5

[John Daggett (:jtd)]

I think the real solution here will be to move the font loader off the main thread but that's going to take a significant amount of refactoring so for now this seems fine.  There will still be situations where a hang will occur (e.g. with crappy netbooks at cold startup when startup occurs shortly after a system restart) but hopefully we'll have more chromehang data to distinguish these cases from cases.

Comment 6

[Jonathan Kew [:jfkthame]]

Agreed, that's more like a real solution - this is just a band-aid that is intended to mitigate the problem somewhat, at least for some of the chrome-hang cases.

https://hg.mozilla.org/integration/mozilla-inbound/rev/9bc938b8f1f0
https://hg.mozilla.org/integration/mozilla-inbound/rev/49ee3d96c62b

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/9bc938b8f1f0
https://hg.mozilla.org/mozilla-central/rev/49ee3d96c62b