1866107 - 5.27 - 3.78% tabpaint / tabpaint + 1 more (Windows) regression on Tue November 14 2023

Status: RESOLVED WONTFIX

(Core :: DOM: Navigation, defect)

Description

[Andrej (:aglavic)]

Perfherder has detected a talos performance regression from push f768135b85f29ef20a22825a054d1a6938475ba5. 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)
5%	tabpaint	windows10-64-shippable-qr	e10s fission stylo webrender	54.93 -> 57.82
4%	tabpaint	windows10-64-shippable-qr	e10s fission stylo webrender-sw	55.40 -> 57.61
4%	tabpaint	windows10-64-shippable-qr	e10s fission stylo webrender	55.24 -> 57.32

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.

For more information on performance sheriffing please see our FAQ.

Comment 1

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

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

Comment 2

[Andreas Farre [:farre]]

I tried a perf run with bug 1746524 backed out, and I didn't get the same level of regression. Also, the webrender-sw is a Tier 2 test.

I'm not sure if this is such a big, deal. What do you think :mconley? Is it worth blocking parent controlled navigation due to this?

Note that these perf runs have profiling turned on, which explains the higher numbers.

Comment 3

[Mike Conley (:mconley) (:⚙️)]

I'd be curious to see a try push with the regression and profiling turned on so that we could do a comparison. It's probably a long shot given how low magnitude the regression is, but I'd be curious to see if there's anything obvious that jumps out when we compare that to profiles of the test with the preference disabled.

Comment 4

[Andreas Farre [:farre]]

So profiling is turned on:

With pcn:

• cycle 1
• cycle 2

Without pcn:

• cycle 1
• cycle 2

It does indeed look like web-content starts later with pcn in cycle 1. Cycle 2 is pretty similar with and without.

Looking at subtests it looks like tabpaint-from-parent is the culprit. But I don't know how that's measured.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

I think the only thing that jumps out at me from these profiles is the fact that we do a GC during the "with PCN" case in Cycle 1 during the "opening from parent" subtest: https://share.firefox.dev/3Go0QkG

The way tabpaint works is that it opens a tab in two ways:

1. It opens a new tab by calling gBrowser.addTab in the parent process.
2. It opens a new tab from content by sending a message to the content process to open a new tab clicking on an anchor element with target="_blank".

Considering the improvements from PCN in https://bugzilla.mozilla.org/show_bug.cgi?id=1746524#c44, and the fact that the regression seems to be an artifact from (at least) some GC'ing only during the first cycle and not for subsequent cycles, and the fact that the magnitude is quite low, I think we can close this as WONTFIX.