2.14% Base Content Heap Unclassified (Linux) regression on Sun March 13 2022
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr91 | --- | unaffected |
firefox98 | --- | unaffected |
firefox99 | --- | unaffected |
firefox100 | --- | wontfix |
People
(Reporter: aglavic, Unassigned)
References
(Regression)
Details
(Keywords: perf, perf-alert, regression)
Perfherder has detected a awsy performance regression from push e349896dac17967f530002b8a093092d4c7cffe1. 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) |
---|---|---|---|---|
2% | Base Content Heap Unclassified | linux1804-64-shippable-qr | 1,986,578.00 -> 2,029,086.67 | |
2% | Base Content Heap Unclassified | linux1804-64-shippable-qr | 1,986,922.00 -> 2,029,048.00 |
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.
Comment 1•3 years ago
|
||
Set release status flags based on info from the regressing bug 1758721
Comment 2•3 years ago
|
||
This is not surprising, given that bug 1758721 by design preloads a collection of prefs into memory (so that we won't need to use the Preferences service during text shaping). So there's bound to be some memory footprint for this.
Eventually, we could consider mitigating this by moving the cached prefs to some kind of shared-memory record, so that there wouldn't be a per-process overhead but only a single instance, but this will require coming up with an efficient shared-memory version of a hashtable, or other form of storage for the cache; and dealing carefully with updating and synchronization. This could be tricky to get right, and the payoff is relatively small (looks like the total regression reported here is around 40K), so I don't think it's a high priority and it shouldn't block the offscreen-canvas text work that motivated the original patch.
Accordingly, I think we should accept this, at least for now, and close as WontFix. @lsalzman, do you agree that's OK?
Comment 3•3 years ago
|
||
It doesn't seem that concerning a regression, at least not so much that it would justify adding a new complicated inter-process mechanism to work around it. Accepting it is fine with me.
Updated•3 years ago
|
Updated•3 years ago
|
Description
•