1921997 - 4.6 - 2.08% google-mail FirstVisualChange / twitter loadtime + 28 more (Windows) regression on Sat September 28 2024

Status: RESOLVED FIXED

(Firefox :: Sidebar, defect)

Description

[Treeherder Bug Filer]

Perfherder has detected a browsertime performance regression from push e488803f8f2d64a0eb122de50f6f74e596f012ff. 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)	Performance Profiles
5%	google-mail FirstVisualChange	windows11-64-shippable-qr	fission warm webrender	545.83 -> 570.96	Before/After
5%	google-mail ContentfulSpeedIndex	windows11-64-shippable-qr	fission warm webrender	546.83 -> 571.96	Before/After
5%	office ContentfulSpeedIndex	windows11-64-shippable-qr	fission warm webrender	299.43 -> 312.99	Before/After
4%	google-mail SpeedIndex	windows11-64-shippable-qr	fission warm webrender	548.06 -> 572.38	Before/After
4%	google-mail PerceptualSpeedIndex	windows11-64-shippable-qr	fission warm webrender	552.80 -> 577.09	Before/After
4%	instagram largestContentfulPaint	windows11-64-shippable-qr	fission warm webrender	577.35 -> 599.21	Before/After
4%	pinterest PerceptualSpeedIndex	windows11-64-shippable-qr	fission warm webrender	711.38 -> 736.39	Before/After
4%	pinterest loadtime	windows11-64-shippable-qr	fission warm webrender	604.25 -> 625.40	Before/After
3%	office fcp	windows11-64-shippable-qr	fission warm webrender	205.44 -> 211.82	Before/After
3%	office fcp	windows11-64-shippable-qr	cold fission webrender	345.34 -> 356.00	Before/After
...	...	...	...	...	...
2%	twitter PerceptualSpeedIndex	windows11-64-shippable-qr	bytecode-cached fission warm webrender	306.45 -> 313.81	Before/After
2%	google-mail loadtime	windows11-64-shippable-qr	fission warm webrender	215.20 -> 220.28	Before/After
2%	twitter SpeedIndex	windows11-64-shippable-qr	bytecode-cached fission warm webrender	468.64 -> 479.02	Before/After
2%	twitter LastVisualChange	windows11-64-shippable-qr	bytecode-cached fission warm webrender	648.96 -> 663.11	Before/After
2%	twitter loadtime	windows11-64-shippable-qr	bytecode-cached fission warm webrender	307.93 -> 314.33	Before/After

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 2294

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 [e-mail].

Comment 1

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

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

Comment 2

[Emilio Cobos Álvarez (:emilio)]

It's a somewhat surprising regression (bug 1921257 is a front-end change that actually shouldn't have affected rendering at all without overlapping items). I guess by using z-index in the #tabbrowser-tabbox I created a stacking context, which somehow tripped WebRender over or something?

Glenn, does WebRender have any optimization that assumes that tabs are drawn in the topmost stacking context or something? I don't understand how my patch could make stuff slower...

Comment 3

[Emilio Cobos Álvarez (:emilio)]

In any case, I guess given the scale of the regression, and that it is a cosmetic issue that still needs more work, we can back out the regressor for now.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Oh, I didn't realize the regression is somehow windows-specific... Really weird

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Fixed by backout, but we should figure out the regression here, somehow. My guess is that painting the content on top of the toolbox would fix this (and this patch kinda broke it).

Comment 6

[Glenn Watson [:gw]]

It's hard to say from that - we would probably need profiles from before / after to get a sense of where the difference is. One possibility is that the change may be triggering a rarely used shader combination / compilation that wasn't previously being hit, which can sometimes skew perf regression tests even if the actual rasterization time is the same.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

There are profiles in comment 0 (the last column). Do those help? I didn't see anything too obvious fwiw...

Some things that stand out:

• This is windows only, which is weird.
• This is warm pageload only (which ideally would mean we don't hit that shader compilation issue?)

I took a look at some of the profiles and ironically long composites are on the "before" profile, which is very weird.

Comment 8

[Glenn Watson [:gw]]

The timings in the renderer thread do look a bit different in those profiles. It's hard to know whether that's significant in this case or just noise in the profile though. It might be interesting (though probably not easy) to capture the output from the WR profiler overlay (such as number of picture cache tiles that are being rasterized, number of primitives and batches etc). Maybe we should look at exposing those as counters / markers in the Fx profiler.