Closed Bug 1371157 Opened 3 years ago Closed 3 years ago

cache results of system font lookups on Windows

Categories

(Core :: Widget: Win32, defect)

x86
Windows 10
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla55
Tracking Status
firefox55 --- fixed

People

(Reporter: dbaron, Assigned: dbaron)

References

(Blocks 1 open bug)

Details

(Keywords: perf, Whiteboard: [qf:p1])

Attachments

(2 files)

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.
MozReview-Commit-ID: 8bwmXmBFZB4
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)
Whiteboard: [qf] → [qf:p1]
Attachment #8875806 - Flags: review?(jmathies) → review+
Attachment #8875807 - Flags: review?(jmathies) → review+
https://hg.mozilla.org/mozilla-central/rev/aa3557e8515c
https://hg.mozilla.org/mozilla-central/rev/70c026121670
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
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.