Closed Bug 683808 Opened 13 years ago Closed 10 years ago

Android calls into XPIProvider.jsm causing nsIPrefService.savePrefFile IO on main thread during startup

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mfinkle, Unassigned)

References

Details

(Whiteboard: mobilestartupshrink)

Some of the toolkit code calls this during startup. On some Android devices this can take ~45ms per call. I see it called twice during initial startup and called once on subsequent startups. I found the place where it's always called during startup: http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/XPIProvider.jsm#3219 This is also called on Android when we go into the background. Again, it takes the same ~45ms, but it probably hurts overall performance less in this situation.
Whiteboard: mobilestartupshrink
OS: Linux → All
Hardware: x86 → All
I'm a little surprised that that is getting called on every startup, I'd love to see JS stacks for that to try to figure out why
I had a startup log generated from the function timer stuff from a recent desktop Nightly build on Mac, and this didn't show up.
It's getting called because we request the list of recommended add-ons. Something only mobile does. I'm looking at ways around it. Mobile also calls savePrefFile when going to the background.
(In reply to Mark Finkle (:mfinkle) from comment #3) > It's getting called because we request the list of recommended add-ons. > Something only mobile does. I'm looking at ways around it. Mobile also calls > savePrefFile when going to the background. I'm still not sure why that'd cause the code referenced in comment 0 to get called
(In reply to Dave Townsend (:Mossop) from comment #4) > (In reply to Mark Finkle (:mfinkle) from comment #3) > > It's getting called because we request the list of recommended add-ons. > > Something only mobile does. I'm looking at ways around it. Mobile also calls > > savePrefFile when going to the background. > > I'm still not sure why that'd cause the code referenced in comment 0 to get > called http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/XPIProvider.jsm#4975 getStatement() calls .connection property, which calls .openConnection(), and I menat: http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/XPIProvider.jsm#4209
(In reply to Mark Finkle (:mfinkle) from comment #5) > (In reply to Dave Townsend (:Mossop) from comment #4) > > (In reply to Mark Finkle (:mfinkle) from comment #3) > > > It's getting called because we request the list of recommended add-ons. > > > Something only mobile does. I'm looking at ways around it. Mobile also calls > > > savePrefFile when going to the background. > > > > I'm still not sure why that'd cause the code referenced in comment 0 to get > > called > > http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/ > XPIProvider.jsm#4975 > > getStatement() calls .connection property, which calls .openConnection(), > and I menat: > http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/ > XPIProvider.jsm#4209 Ah that makes more sense. That code looks dumb and shouldn't need to flush the prefs everytime
Linking this up with the /other/ bug about this, plus making this specific to the XPIProvider.jsm case per comment #6.
Component: Startup and Profile System → Add-ons Manager
Depends on: 789945
Summary: nsIPrefService.savePrefFile blocks IO on main thread → Android calls into XPIProvider.jsm causing nsIPrefService.savePrefFile IO on main thread during startup
mfinkle/gijs: can you find the lines from comment 5 in the current code base? All the database connection stuff was removed in the SQLITE => JSON change; the only place I can see now where we explicitly call savePrefFile() is at http://hg.mozilla.org/mozilla-central/annotate/5ea30521f56b/toolkit/mozapps/extensions/internal/XPIProvider.jsm#l3832, which should only happen when we're switching themes.
Flags: needinfo?(mark.finkle)
I don't see the code in the existing codebase anymore. Let's assume it's "fixed" until we see something in profiles again.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(mark.finkle)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.