Profiling bug 1118086 on Windows shows that about 8% of the time in the big pause in the parent process to render a large select is time spent in mozilla::LookAndFeel::GetFont. See the profile in https://perfht.ml/2qYJjqQ . (Contrast with Linux, where time was spent in GetWidgetPadding / GetWidgetBorder; see bug 1367576.) Caching the results of these repeated system font lookups should be a performance win, and should be pretty straightforward.
Attachment #8875806 - Flags: review?(jmathies)
I haven't really tested that this fixes the performance problem observed in a profile without the patch because the steps to use the Gecko Profiler on local builds on Windows are rather complicated. MozReview-Commit-ID: FmGFs2Cvquv
Attachment #8875807 - Flags: review?(jmathies)
(The instructions for the "rather complicated" bit are: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler_and_Local_Symbols_on_Windows , for what it's worth.)
https://hg.mozilla.org/integration/mozilla-inbound/rev/aa3557e8515c8a8a1cbab8f5a5614476cc68ffe6 Bug 1371157 - Use override keyword in windows nsLookAndFeel header. r=jimm https://hg.mozilla.org/integration/mozilla-inbound/rev/70c026121670bd42e43bb87334fec1fd848b77d9 Bug 1371157 - Cache results of Windows system font lookups. r=jimm
I verified that it fixed what I expected by reprofiling in today's nightly. In today's nightly, 7ms are spent inside of ComputeFontData: https://perfht.ml/2svcp5g Whereas in the profile from comment 0, that was 172ms: https://perfht.ml/2suzJAk of which 159ms was spent inside nsRuleNode::ComputeSystemFont (compared to 0 in today's nightly).
You need to log in before you can comment on or make changes to this bug.