Closed Bug 1761965 Opened 2 years ago Closed 2 years ago

4.82 - 4.07% Base Content Explicit / Base Content Explicit (Linux) regression on Thu March 24 2022

Categories

(Core :: Graphics: Text, defect)

defect

Tracking

()

RESOLVED FIXED
100 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox98 --- unaffected
firefox99 --- unaffected
firefox100 --- fixed

People

(Reporter: aglavic, Assigned: jfkthame)

References

(Regression)

Details

(Keywords: perf, perf-alert, regression)

Attachments

(1 file)

Perfherder has detected a awsy performance regression from push 5247739359f70e72ea971c0aa85231017b77fd45. As author of one of the patches included in that push, we need your help to address this regression.

Regressions:

Ratio Test Platform Options Absolute values (old vs new)
5% Base Content Explicit linux1804-64-shippable-qr 7,715,909.33 -> 8,087,877.33
4% Base Content Explicit linux1804-64-shippable-qr 7,757,466.67 -> 8,073,029.33

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests. Please follow our guide to handling regression bugs and let us know your plans within 3 business days, or the offending patch(es) will be backed out in accordance with our regression policy.

For more information on performance sheriffing please see our FAQ.

Flags: needinfo?(jfkthame)

Set release status flags based on info from the regressing bug 1759988

The only change in bug 1759988 was to ensure we don't miss calling InitializeCodepointsWithNoFonts() during font-list initialization. I'm surprised that would show up as a significant regression, as it's not very big/complex, but nevertheless, we should be able to optimize it a bit.

Since creating the FontVisibility settings, we now have multiple versions of the "no font is available" bitset, one for each font visibility level, as they may diverge as documents with different visibility privileges attempt to find fallback fonts. But they all get initialized to the same standard settings, to just exclude control characters, PUA codepoints, and Unicode noncharacter codepoints. So we can just construct the initialized bitset once and then duplicate it, instead of re-creating it from scratch for each visibility level.

In local testing with my macOS build, this saves around 100µs per call to InitializeCodepointsWithNoFonts(), which is called at least once per process, and may be called again as a result of lazy-init updates to the font data.

Flags: needinfo?(jfkthame)
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Attachment #9269866 - Attachment description: Bug 1761965 - Accelerate InitializeCodepointsWithNoFonts() by only constructing the bitset incremetally once, then copying it to the other array entries. r=lsalzman → Bug 1761965 - Accelerate InitializeCodepointsWithNoFonts() by only constructing the bitset incrementally once, then copying it to the other array entries. r=lsalzman
Pushed by jkew@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/902bbafd4039
Accelerate InitializeCodepointsWithNoFonts() by only constructing the bitset incrementally once, then copying it to the other array entries. r=lsalzman
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 100 Branch
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: