1993942 - 21.88 - 9.7% tresize / sessionrestore_no_auto_restore + 4 more (Windows) regression on Mon October 6 2025

Status: RESOLVED WONTFIX

(Core :: Widget: Win32, defect)

Description

[Treeherder Bug Filer]

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

Please acknowledge, and begin investigating this alert within 3 business days, or the patch(es) may be backed out in accordance with our regression policy. Our guide to handling regression bugs has information about how you can proceed with this investigation.

If you have any questions or need any help with the investigation, please reach out to [e-mail]. Alternatively, you can find help on Slack by joining #perf-help, and on Matrix you can find help by joining #perftest.

Regressions:

Ratio	Test	Platform	Options	Absolute values (old vs new)
22%	tresize	windows11-64-24h2-shippable	e10s fission stylo webrender-sw	5.22 -> 6.36
21%	twinopen ext+twinopen:twinopen.html	windows11-64-24h2-shippable	e10s fission stylo webrender	80.95 -> 97.63
19%	twinopen ext+twinopen:twinopen.html	windows11-64-24h2-shippable	e10s fission stylo webrender-sw	74.70 -> 89.07
13%	ts_paint_webext	windows11-64-24h2-shippable	e10s fission stylo webrender	330.54 -> 372.08
10%	ts_paint	windows11-64-24h2-shippable	e10s fission stylo webrender-sw	299.08 -> 329.83
10%	sessionrestore_no_auto_restore	windows11-64-24h2-shippable	e10s fission stylo webrender-sw	337.29 -> 370.00

Details of the alert can be found in the alert summary, including links to graphs and comparisons for each of the affected tests.

If you need the profiling jobs you can trigger them yourself from treeherder job view or ask [e-mail] to do that for you.

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

The following documentation link provides more information about this command.

Comment 1

[Greg Stoll :gstoll]

My guess is that doing the Windows App SDK stuff that bug 1947324 added is adding some time here. I'm going to see if I can defer that so it doesn't synchronously block session restore, etc.

Comment 2

[Greg Stoll :gstoll]

Confusingly, a simple change to do this asynchronously didn't seem to fix the issue.

I'm going to try again with a more recent build. I'm also wondering if the sessionrestore regression may be caused by bug 1968297, which went in around the same time. (and should just be a change in measurement, not anything real)

Comment 3

[Greg Stoll :gstoll]

That didn't work either. I'm going to try reverting bug 1968297 and see if that makes a difference.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 5

[Greg Stoll :gstoll]

OK, a comparison with a full revert of bug 1968297 does seem to get things back to normal (albeit with low confidence). I'm going to try some other stuff.

Comment 6

[Greg Stoll :gstoll]

Sadly, nothing I tried helped. We have to call the Windows App SDK functions on the main thread, and calling them asynchronously with NS_DispatchToMainThreadQueue() doesn't seem to help the recorded performance. I think we have to live with this given that the only other option is reverting bug 1968297.