13.94% fandom loadtime (Linux) regression on Mon November 21 2022
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr102 | --- | unaffected |
| firefox107 | --- | unaffected |
| firefox108 | --- | unaffected |
| firefox109 | --- | fixed |
People
(Reporter: aesanu, Assigned: jfkthame)
References
(Regression)
Details
(Keywords: perf, perf-alert, regression)
Attachments
(1 file)
Perfherder has detected a browsertime performance regression from push e405b207d96693ff06d72a4bf4fbecf8e82946ac. 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) |
|---|---|---|---|---|
| 14% | fandom loadtime | linux1804-64-shippable-qr | bytecode-cached cold fission webrender | 1,035.52 -> 1,179.82 |
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) may be backed out in accordance with our regression policy.
If you need the profiling jobs you can trigger them yourself from treeherder job view or ask a sheriff to do that for you.
For more information on performance sheriffing please see our FAQ.
|
Assignee | |
Comment 1•1 year ago
|
||
The graph for this testcase here seems quite noisy, but yes, it does appear to show a regression -- I guess this must be due to the cost of parsing and normalizing the locale code (TryParse and AddLikelySubtags) during font selection.
On the other hand, the improvements shown e.g. here are quite clear and substantial, and are a direct result of doing this new processing.
So it's a trade-off: we're doing a little more work, which may slightly regress overall font selection performance (although on most testcases it doesn't show up as a measureable regression), in order to avoid the risk of much worse performance problems in extreme cases (e.g. see bug 1787603 comment 25: reflow dropped from 9.2 to 1.1 seconds).
As such, I'd be prepared to accept this regression as a cost of the improvement seen on other cases; but I do have an idea that might also mitigate this and give us the "best of both worlds", so keeping this open to experiment with a possible fix.
|
|
Assignee | |
Comment 2•1 year ago
|
||
No change in behavior; this just makes successive calls to
FindAndAddFamiliesLocked slightly cheaper when the same lang
atom is used repeatedly (which is overwhelmingly the usual
case).
|
||
Updated•1 year ago
|
|
||
Comment 3•1 year ago
|
||
Set release status flags based on info from the regressing bug 1787603
Pushed by jkew@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6f58c7ad7fba Avoid repeatedly parsing/expanding the same locale code. r=emilio
|
||
Comment 5•1 year ago
|
||
| bugherder | ||
|
|
Assignee | |
Updated•1 year ago
|
Description
•