Open Bug 1955585 Opened 10 months ago Updated 10 days ago

3.54% startup_about_home_paint_cached (Windows) regression on Mon March 17 2025

Categories

(Firefox :: New Tab Page, defect, P3)

defect

Tracking

()

Tracking Status
firefox-esr128 --- unaffected
firefox136 --- unaffected
firefox137 --- unaffected
firefox138 --- wontfix
firefox139 --- wontfix

People

(Reporter: intermittent-bug-filer, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(5 keywords, Whiteboard: [hnt-trainhop-project])

Perfherder has detected a talos performance regression from push a6810a0e042eb4307273bcf0ec3e28ba744f3f57. 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)
4% startup_about_home_paint_cached windows11-64-24h2-shippable e10s fission stylo webrender-sw 421.17 -> 436.08

Improvements:

Ratio Test Platform Options Absolute values (old vs new)
8% tp5n main_startup_fileio windows11-64-24h2-shippable e10s fission stylo webrender 409,693.85 -> 375,351.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 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.

You can run all of these tests on try with ./mach try perf --alert 44405

The following documentation link provides more information about this command.

For more information on performance sheriffing please see our FAQ.

If you have any questions, please do not hesitate to reach out to fbilt@mozilla.com.

Flags: needinfo?(mconley)

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

Flags: needinfo?(mconley)
Whiteboard: [hnt-trainhop]

Okay, I suspected something like this might occur, since we have to wait for the newtab extension to be enabled before we let the cache be retrieved.

There might be an optimization we can make here, but considering the low severity of the regression and the high-priority in keeping newtab packaged this way, I'd like to keep this bug on file as something to address down the line, but to not back out bug 1949511.

It has been over 7 days with no activity on this performance regression.

:mconley, since you are the author of the regressor, bug 1949511, which triggered this performance alert, could you please provide a progress update?

If this regression is something that fixes a bug, changes the baseline of the regression metrics, or otherwise will not be fixed, please consider closing it as WONTFIX. See this documentation for more information on how to handle regressions.

For additional information/help, please needinfo the performance sheriff who filed this alert (they can be found in comment #0), or reach out in #perftest, or #perfsheriffs on Element.

For more information, please visit BugBot documentation.

Flags: needinfo?(mconley)

Yes, I have a status update. I think what we probably want to do here is, in the event that reach the loading of about:home in the parent process and we've determined that an about:home cache exists, we shouldn't suspend that request even if the newtab XPI isn't yet loaded. Instead, let the request go through, and let the cache be loaded. The caveat here is that we can no longer easily / reliably race the cache against the dynamic load of about:home (without more complexity). That might be fine for the common case though - we'd just have the child's channel wait until the pipes get sent their bytes (which we know they should, since we know that the parent has a cache available).

Flags: needinfo?(mconley)

The severity field is not set for this bug.
:thecount, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(sdowne)
Severity: -- → S4
Flags: needinfo?(sdowne)
Priority: -- → P3

It has been over 7 days with no activity on this performance regression.

:mconley, since you are the author of the regressor, bug 1949511, which triggered this performance alert, could you please provide a progress update?

If this regression is something that fixes a bug, changes the baseline of the regression metrics, or otherwise will not be fixed, please consider closing it as WONTFIX. See this documentation for more information on how to handle regressions.

For additional information/help, please needinfo the performance sheriff who filed this alert (they can be found in comment #0), or reach out in #perftest, or #perfsheriffs on Element.

For more information, please visit BugBot documentation.

Flags: needinfo?(mconley)

Hi! My update is that we plan on working on this, but that it's likely going to be a few weeks until we get to it - and that we're willing to accept the (very) small regression in about:home rendering time in order to package New Tab this way. Backing out is, I'm afraid, simply not an option.

So please give us more time. We will get to this.

Flags: needinfo?(mconley)
Whiteboard: [hnt-trainhop] → [hnt-trainhop],
Whiteboard: [hnt-trainhop], → [hnt-trainhop-project]
You need to log in before you can comment on or make changes to this bug.