Last Comment Bug 699331 - Investigate name enumeration time at startup
: Investigate name enumeration time at startup
Status: RESOLVED FIXED
[Snappy:P1]
:
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla23
Assigned To: Jonathan Kew (:jfkthame)
:
:
Mentors:
Depends on:
Blocks: 859558
  Show dependency treegraph
 
Reported: 2011-11-02 22:28 PDT by John Daggett (:jtd)
Modified: 2013-04-26 18:45 PDT (History)
13 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Hangs in gfxFontFamily::ReadFaceNames() (2.03 KB, text/plain)
2013-04-08 16:36 PDT, Vladan Djeric (:vladan)
no flags Details
pt 1 - replace hardcoded font-loader constants with prefs to allow easier tuning (10.41 KB, patch)
2013-04-22 05:19 PDT, Jonathan Kew (:jfkthame)
jd.bugzilla: review+
Details | Diff | Splinter Review
pt 2 - read info for fewer families each time the font-loader runs (1.92 KB, patch)
2013-04-22 05:20 PDT, Jonathan Kew (:jfkthame)
jd.bugzilla: review+
Details | Diff | Splinter Review

Description John Daggett (:jtd) 2011-11-02 22:28:40 PDT
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) 2013-04-08 16:36:27 PDT
Created attachment 734892 [details]
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) 2013-04-22 05:19:22 PDT
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) 2013-04-22 05:19:44 PDT
Created attachment 740247 [details] [diff] [review]
pt 1 - replace hardcoded font-loader constants with prefs to allow easier tuning
Comment 4 Jonathan Kew (:jfkthame) 2013-04-22 05:20:11 PDT
Created attachment 740248 [details] [diff] [review]
pt 2 - read info for fewer families each time the font-loader runs
Comment 5 John Daggett (:jtd) 2013-04-25 22:33:59 PDT
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) 2013-04-26 00:45:36 PDT
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

Note You need to log in before you can comment on or make changes to this bug.