Open Bug 1502145 Opened 6 years ago Updated 1 year ago

[Geckoview] Kinto stuff taking lots of main thread time

Categories

(GeckoView :: General, enhancement, P3)

Unspecified
Android
enhancement

Tracking

(geckoview62 wontfix, geckoview63 wontfix, firefox63 wontfix, firefox64 wontfix, firefox65 ?)

Tracking Status
geckoview62 --- wontfix
geckoview63 --- wontfix
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- ?

People

(Reporter: smaug, Unassigned)

References

Details

Depends on: 1502146
@ Olli or Vicky: Which Gecko version is vchin's profile using? Is this problem GeckoView-specific?

@ Mathieu: Does this problem with Kinto hogging the main thread sound familiar? Has this issue been fixed in 64 by bug 1486980?

Should we move this bug to the "Firefox::Remote Settings Client" component?
Flags: needinfo?(mathieu)
OS: Unspecified → Android
Priority: -- → P1
(In reply to Chris Peterson [:cpeterson] from comment #2)
> @ Olli or Vicky: Which Gecko version is vchin's profile using? Is this
> problem GeckoView-specific?
This is with the latest geckoview_example off Mozilla Central.
I believe it is GV specific. Using Klar with Webview loads pretty fast.
Here's the site I was loading:
google.com/maps/place/Mozilla,+331+E+Evelyn+Ave,+Mountain+View,+CA+94041,+USA/@37.3873148,-122.0600095,17z/data=!4m2!3m1!1s0x808fba016663a837:0x1d64663c633a9e5?force=pwa

> 
> @ Mathieu: Does this problem with Kinto hogging the main thread sound
> familiar? Has this issue been fixed in 64 by bug 1486980?
> 
> Should we move this bug to the "Firefox::Remote Settings Client" component?
> It is not only IndedexDB stuff taking time, but script running before IDB.

I think I'd need a training to read perf graphs. I believe I see something in the flame graph, but the largest operations seems to be an IDB put operation.

> Should we move this bug to the "Firefox::Remote Settings Client" component?

The kinto-offline lib is also used by the WebExtension storage.sync API. If the caller is Remote Settings, then yes.

> Does this problem with Kinto hogging the main thread sound familiar? Has this issue been fixed in 64 by bug 1486980?

Well, the hogging issue we had is mainly due to Bug 1499550. In Bug 1486980, we limited the damage by reducing the collection size and by rewriting a couple of things, but we'll ship another workaround in Bug 1499738. 

> This is with the latest geckoview_example off Mozilla Central.

I don't think it's related to GeckoView, I'd be very interested to see the link to kinto :)
Flags: needinfo?(mathieu)
(In reply to Vicky Chin [:vchin] from comment #4)
> (In reply to Chris Peterson [:cpeterson] from comment #2)
> > @ Olli or Vicky: Which Gecko version is vchin's profile using? Is this
> > problem GeckoView-specific?
> This is with the latest geckoview_example off Mozilla Central.
> I believe it is GV specific. Using Klar with Webview loads pretty fast.

I meant: does the problem happen in both Fennec Nightly and Focus+GV?
No longer depends on: 1486980
64=wontfix because this issue doesn't block Focus 8.0 from using GV 64.
Vicky, how frequently does this Kinto hang happen? Does this only happen on first run? How long/serious is the hang?
Flags: needinfo?(vchin)
Priority: P1 → P2
Summary: [Geckoview] kinto stuff taking lots of main thread time → [Geckoview] Kinto stuff taking lots of main thread time
If you can, I would be interested to see the impact of the patch of Bug 1502146 (it divided by 10x the use of main thread)
Product: Firefox for Android → GeckoView

I'm editing a bunch of GeckoView bugs. If you'd like to filter all this bugmail, search and destroy emails containing this UUID:

e88a5094-0fc0-4b7c-b7c5-aef00a11dbc9

Priority: P2 → P3
Flags: needinfo?(vchin)
Severity: normal → S3

Tasks and enhancements should have severity N/A.

Severity: S3 → N/A
You need to log in before you can comment on or make changes to this bug.