Closed Bug 1939885 Opened 1 month ago Closed 1 month ago

0.26% Images Tabs closed [+30s, forced GC] (Windows) regression on Fri November 29 2024

Categories

(Core :: Disability Access APIs, defect)

defect

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox-esr128 --- unaffected
firefox133 --- unaffected
firefox134 --- unaffected
firefox135 --- affected

People

(Reporter: intermittent-bug-filer, Unassigned)

References

(Regression)

Details

(Keywords: perf, perf-alert, regression)

Perfherder has detected a awsy performance regression from push 7a2a7922871a61190c7b6777894e3b669ff20c7a. 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)
0.26% Images Tabs closed [+30s, forced GC] windows11-64-2009-shippable-qr fission tp6 1,677,838.00 -> 1,682,193.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 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 43248

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 afinder@mozilla.com.

Flags: needinfo?(eitan)

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

Is accessibility even on during this test? If not, it is impossible for bug 1919155 to have caused this.

Flags: needinfo?(eitan)

The values of this measurement before this regression are: 1680672, 1680256, 1680256, 1680256.

The values after are: 1682176, 1682176, 1682176, 1682176, 1682176.

So, it seems like there's a change, but it is only 1504 bytes, not the 4355 bytes in comment 0. Maybe the failure in the before state somehow threw off the average? I dunno how that works. I looked at the memory logs before and after, but I'm not sure where these values are even coming from. It is interesting that this measurement is so consistent but the actual change is extremely tiny so let's not worry about it.

Status: NEW → RESOLVED
Closed: 1 month ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.