Closed Bug 1505258 Opened 6 years ago Closed 3 years ago

Loading mobile Instagram site takes 2x longer using GeckoView

Categories

(Core :: JavaScript Engine, defect, P3)

65 Branch
ARM
Android
defect

Tracking

()

RESOLVED WORKSFORME
Performance Impact high
Tracking Status
firefox65 --- wontfix
firefox66 --- affected

People

(Reporter: vchin, Assigned: squib)

References

Details

(Keywords: perf, perf:pageload)

The first profile is taken on the Geckoview Example App on the Moto G5 Site: https://www.instagram.com/p/BpmwEd7lMI8 Profile: https://perfht.ml/2zzmuQk I can reproduce on desktop (Macbook Pro) using a UA switcher to Android Profile: https://perfht.ml/2zw1lXa
Whiteboard: [qf:p1:pageload]
I timed the page load manually: Focus with GV 64 takes 10 seconds load Focus with Webview takes 5 seconds to load Page load for desktop site loads great and don't show the same issues in the profile.
Assignee: nobody → jporter+bmo
Status: NEW → ASSIGNED
The issue here seems to just be slow start-up execution of javascript by the engine. The major paths forward for fixing this are just interpreter speed improvements, of which many are on the way. Related bugs: 1. Object-biased NaN-boxing https://bugzilla.mozilla.org/show_bug.cgi?id=1401624#c63 2. Generated interpreter + interpreter ICs. 3. Property lookup optimizations (e.g. Shape table lookup opt). - Denis is working on this but I can't find the bugno at the moment.
Priority: -- → P1

This should be re-evaluated with scheduling in mind. I don't think we can rely on the "slow JS" conclusion anymore, and it seems the 2x differential is likely much more related to potential issues with event and paint scheduling during page load.

Priority: P1 → P3

(Moved to P3 as this is ARM)

OS: Unspecified → Android
Hardware: Unspecified → ARM

I tested this again, and it still seems considerably worse than Chrome on mobile. Kannan, do you have any particular changes in mind that would be worth investigating to improve this?

Flags: needinfo?(kvijayan)

I think this is a great candidate for the TraceLogger. Specifically, the next step here is to compare the JS execution in Chrome and Firefox on a script-by-script basis. The first thing to rule out is whether or not the load issues are due to some other scheduling difference.

With the TraceLogger, it should be a lot easier now to get a running log of which scripts were executed when and compare against Chrome's profiler's trace data.

We want to cross-reference the script execution and durations against each other and also against paint and domContentLoaded events.

Flags: needinfo?(kvijayan)

This seems fine to me on the Pixel 2:
Fenix: Load: 2.19s (σ413.00ms), speedIndex: 2.38s (σ340.00ms), visualComplete85: 2.59s (σ399.00ms)
Chrome: Load: 1.80s (σ130.00ms), speedIndex: 2.25s (σ877.00ms), visualComplete85: 2.45s (σ860.00ms)

On a S7:
Fenix: Load: 3.15s (σ327.00ms), speedIndex: 3.56s (σ440.00ms), visualComplete85: 4.10s (σ544.00ms)
Chrome: Load: 3.21s (σ1.10s), speedIndex: 3.25s (σ1.09s), visualComplete85: 3.61s (σ1.10s)

This also looks fine to me. Going to close this as WFM.

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
Performance Impact: --- → P1
Keywords: perf:pageload
Whiteboard: [qf:p1:pageload]
You need to log in before you can comment on or make changes to this bug.