Closed Bug 1458079 Opened 3 years ago Closed 2 years ago

Nimbledroid's page load test is 2x slower in GeckoView than WebView


(GeckoView :: General, defect, P2)



(firefox-esr52 wontfix, firefox-esr60 wontfix, firefox59 wontfix, firefox60 wontfix, firefox61 wontfix, firefox62 wontfix, firefox65 wontfix, firefox66 affected, firefox67 affected, firefox68 affected)

Tracking Status
firefox-esr52 --- wontfix
firefox-esr60 --- wontfix
firefox59 --- wontfix
firefox60 --- wontfix
firefox61 --- wontfix
firefox62 --- wontfix
firefox65 --- wontfix
firefox66 --- affected
firefox67 --- affected
firefox68 --- affected


(Reporter: cpeterson, Unassigned)


(Depends on 1 open bug, Blocks 1 open bug)


(Whiteboard: [qf:p1:pageload][qf:js:investigate])

Nimbledroid test results for

Klar+WebView = 3.7 seconds

Klar+GeckoView = 7.7 seconds

Klar+WebView test results on Nimbledroid:

GeckoView and WebView test results spreadsheet:
Whiteboard: [qf] → [geckoview:klar] [qf]
Hey cpeterson, does this impact Desktop? If not, I don't think this is something the Quantum Flow team is currently triaging.
Flags: needinfo?(cpeterson)
P2 feels right as a default for performance bugs tied to our nimbledroid informed perf work.
Priority: -- → P2
Whiteboard: [geckoview:klar] [qf] → [geckoview:klar]
Here is a profile of Firefox Nightly 62 on Windows 10 loading The page load takes about 1 second in Chrome and almost 3 seconds in Firefox.
Flags: needinfo?(cpeterson)
Whiteboard: [geckoview:klar] → [geckoview:klar] [qf]
dholbert, there is some slow reflow here. Could you take a look at that part of the profile? Something grid related?
Flags: needinfo?(dholbert)
Ted, can you take a look at the JS execution in this profile?  The problem just seems to be slow JS execution for at least half of the profile here.  Nothing specific seems to stand out.  This might be a good target to include for later-in-the-year JS performance optimization goals.
(In reply to Olli Pettay [:smaug] from comment #4)
> dholbert, there is some slow reflow here. Could you take a look at that part
> of the profile? Something grid related?

Yeah - in particular, there's a single initial reflow that takes 106ms:
(That time -- 106ms -- is what's reported in the tooltip when I hover the blue "reflow" bar.  The "Running Time" samples only total up to 49ms, but I'm assuming that some of those are missing, or they're recorded with the wrong duration or something, since I know that happens on some platforms.  I'm assuming I should trust the measurement on the blue "Reflow" bar more than the sample times.)

The reflow includes nested block -> grid -> flex -> flex containers.  It's hard to know where precisely the issue is coming from, but I'm guessing we're probably re-measuring the same content several times when technically we don't need to.  It's possible bug 1377253's flex-item-size-caching will help with this, and/or we might need to cache size measurements for grid items more aggressively as well.

Anyway -- since there are possible several slow areas here, I'll spin off the layout improvements to a separate bug which I'll mark as blocking this bug.
Flags: needinfo?(dholbert)
Depends on: 1465205
(I spun off bug 1465205 for the layout bits noted in comment 6.)
:djvj wanted to add Ted, done now.
Flags: needinfo?(tcampbell)
Whiteboard: [geckoview:klar] [qf] → [geckoview:klar] [qf][qf:js:investigate]
Whiteboard: [geckoview:klar] [qf][qf:js:investigate] → [geckoview:klar][qf:p1:f67][qf:js:investigate]
Looking at ( -- typically 3s webview vs ~8s geckoview -- there are several interesting things:

1) the top banner appears before loading stops on GV, and after loading stops on WV.  This says that either the site is kicking it off "later", or WV is deciding that process is finished off a different signal, or something along these lines.

2) The profile shows a 1.3s CreatePatternForFace() call which is all FontConfig calls (on Linux).

A bunch of time spent in the jit early on, but that may be ok.
Following up on comment 4 / comment 6 - I suspect the long (106ms) initial reflow here is not a key differentiator between GeckoView & WebView here. I posted some measurements in bug 1465205 comment 2 which indicate that we're actually a good deal faster than Chrome on the initial layout here, at least on desktop. (And 106ms is actually entirely within the range of Chrome-for-desktop first-layout duration for this site.)
Product: Firefox for Android → GeckoView
Whiteboard: [geckoview:klar][qf:p1:f67][qf:js:investigate] → [geckoview:klar][qf:p1:pageload][qf:js:investigate]
Whiteboard: [geckoview:klar][qf:p1:pageload][qf:js:investigate] → [qf:p1:pageload][qf:js:investigate]
Flags: needinfo?(tcampbell)

Chris, could you retest. Lots of changes since this bug was filed, for example bug 1270059.

Flags: needinfo?(cpeterson)

(In reply to Olli Pettay [:smaug] from comment #11)

Chris, could you retest. Lots of changes since this bug was filed, for example bug 1270059.

The Nimbledroid test results for say that GeckoView is now 5x slower than Chrome 72 Beta. I don't trust these Nimbledroid tests and the test results have not be updated since February. I will ask if there is newer data.

I'm going to close this bug as WFM.

Manual comparison of the time to load the full page (ignoring the progress bar and just watching the images at the bottom of the page are loaded) on my Moto G5 for the "VISIT FULL SITE" page linked from the bottom of the mobile page

Fennec 68 Nightly: about 6 seconds
Fenix (GV 67 Beta): about 3 seconds
Chrome 73: about 2 seconds

Closed: 2 years ago
Flags: needinfo?(cpeterson)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.