Closed Bug 1458079 Opened 3 years ago Closed 2 years ago
.com page load test is 2x slower in Gecko View than Web View
Nimbledroid test results for http://www.wikia.com/fandom Klar+WebView = 3.7 seconds Klar+GeckoView = 7.7 seconds Klar+WebView test results on Nimbledroid: https://nimbledroid.com/my_apps/org.mozilla.focus.debug?a=d78f816d-3591-4203-9820-bed76f107406 GeckoView and WebView test results spreadsheet: https://docs.google.com/spreadsheets/d/1vE0b3tawWY9vVNq9Ds6CiA9XZ6LStkcXZl3F8dwXid8/
Hey cpeterson, does this impact Desktop? If not, I don't think this is something the Quantum Flow team is currently triaging.
P2 feels right as a default for performance bugs tied to our nimbledroid informed perf work.
Priority: -- → P2
Here is a profile of Firefox Nightly 62 on Windows 10 loading wikia.com. The page load takes about 1 second in Chrome and almost 3 seconds in Firefox. https://perfht.ml/2LnZBo5
dholbert, there is some slow reflow here. Could you take a look at that part of the profile? Something grid related?
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: https://perfht.ml/2kwk2mi (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.
:djvj wanted to add Ted, done now.
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 http://marvel.wikia.com/wiki/Black_Panther (https://perfht.ml/2ONhGgZ) -- 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.)
Whiteboard: [geckoview:klar][qf:p1:f67][qf:js:investigate] → [geckoview:klar][qf:p1:pageload][qf:js:investigate]
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.