1721611 - 4.21 - 3.27% amazon fcp / amazon fnbpaint + 3 more (Linux) regression on Tue July 6 2021

Status: RESOLVED WONTFIX

(Core :: Widget: Gtk, defect)

Description

[Florin Strugariu [:Bebe]]

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

Regressions:

Ratio	Suite	Test	Platform	Options	Absolute values (old vs new)
4%	amazon	fcp	linux1804-64-shippable-qr	warm webrender	372.04 -> 387.71
4%	amazon	fnbpaint	linux1804-64-shippable-qr	warm webrender	378.62 -> 393.33
4%	amazon	fnbpaint	linux1804-64-shippable-qr	warm webrender	379.12 -> 393.50
4%	amazon	ContentfulSpeedIndex	linux1804-64-shippable-qr	warm webrender	427.62 -> 443.17
3%	amazon	fnbpaint	linux1804-64-shippable-qr	warm webrender	378.31 -> 390.67

Improvements:

Ratio	Suite	Test	Platform	Options	Absolute values (old vs new)
4%	amazon	loadtime	linux1804-64-shippable-qr	warm webrender	571.75 -> 550.50

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 offending patch(es) will be backed out in accordance with our regression policy.

For more information on performance sheriffing please see our FAQ.

Comment 1

[Florin Strugariu [:Bebe]]

Sorry for being late on this but the alert was wrongfully assign to the previous commit
Bug 1720071 - 4.21 - 3.27% amazon fcp / amazon fnbpaint + 2 more (Linux) regression on Tue July 6 2021

Comment 2

[Chris Peterson [:cpeterson]]

Randell, do you have any thoughts on these Amazon perf regressions from Linux semi-headless mode? Is a 4% regression a lot or a little for these particular metrics?

Comment 3

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

One thing that's different with semi-headless is that creating a WebGL context can require calling XOpenDisplay, which does blocking I/O on the main thread (specifically, if there isn't already another WebGL context in the same content process). Previously that was happening early in startup, whether we needed it or not. Amazon does appear to use WebGL in the background for something ad-related, but (1) it's not clear if that happens before the first paint, and (2) in a profile of https://get.webgl.org/, that call takes on the order of 1ms, which doesn't explain the 12-15ms differences we're seeing here. Everything else about WebGL startup, including the costs of loading the libraries/drivers for the first time, shouldn't have changed. Also, I believe there are other sites we test this way which have similar use of WebGL (reddit is in there, and I happen to know they do) but haven't been reported as regressing.

It might also be relevant that the time differences are suspiciously close to one frame at 60Hz. Normally I'd assume that there's enough variation in times between test runs that a small delay wouldn't be more likely than chance to push us over a threshold at that scale, but maybe?

If this isn't something we can fix, I'd argue that we should accept it, given the other improvements from these changes (1.5MB of memory per content process, and 35ms out of ~100ms content process startup time), and given that this regression is relatively small and only seen on one site.

Comment 4

[Chris Peterson [:cpeterson]]

This is not a blocker for Fission.

I will leave the decision on whether to accept this regression and resolve this bug as WONTFIX to someone else.

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

4% is a significant regression; in fission for example we're targeting a max median regression of 5%. However, if this only affects linux in semi-headless mode, not real users, I wouldn't worry much about it. Per above some of these may be 1-frame delays caused by our missing a window to paint for a particular frame, so a small increase in time could cause a 1-frame delay.

Comment 6

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

(In reply to Randell Jesup [:jesup] (needinfo me) from comment #5)

However, if this only affects linux in semi-headless mode, not real users

Those are real users; “semi-headless” was my original name for what shipped as dom.ipc.avoid-gtk and which is on by default.

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Doesn't sound like this regression is going to get any traction. Feel free to reopen and assign if someone's intending to work on it still.