Closed Bug 1359851 Opened 4 years ago Closed 4 years ago
API providers lazily
Here's a profile I captured during start-up: https://perf-html.io/public/75cea1de7333eb66c69f39778d9c21d21e3c2b67/calltree/?implementation=js&range=0.5621_0.6348&thread=0 The part I'm zoomed in on is a ~67ms chunk where we're getting Social API providers, it seems. As far as I can tell, the only place we really use these are for the "Share" button. Assuming the Share button is sticking around, can we load these providers lazily instead of at start-up?
IIRC, the only places we need to know if there are providers is on context menu open and when the share panel is opened. For activity streams share (which seems is no longer part of activity streams?), the share providers are in a button menu dropdown. We should be able to kill any startup, it's been a while since I've looked at the code, but I'll see if there is a simple path forward on that.
(In reply to Mike Conley (:mconley) - PTO on April 28th. from comment #0) > Here's a profile I captured during start-up: > > https://perf-html.io/public/75cea1de7333eb66c69f39778d9c21d21e3c2b67/ > calltree/?implementation=js&range=0.5621_0.6348&thread=0 > > The part I'm zoomed in on is a ~67ms chunk where we're getting Social API > providers, it seems. As far as I can tell, the only place we really use > these are for the "Share" button. > > Assuming the Share button is sticking around, can we load these providers > lazily instead of at start-up? 65ms of this is loading the blocklist.xml file, which is crazy slow, and will be loaded the first time we load an add-on anyway... so let's not blame this on SocialAPI. We are working on improving it in bug 1257565. When looking at the whole profile, the time spent by SocialAPI is: - 2ms in SocialUI_init from browser-social.js, running during _delayedStartup: https://perfht.ml/2plLXJE - 6ms in CreatePocketWidget, which runs very early during startup (maybe that's bug 1359866), when it loads SocialService.jsm https://perfht.ml/2plPo2P That said, we should load Social API (and more generally all modules we don't need during early startup) lazily :-).
Hrm, looking at the profile, it seems that SocialService.getProvider is being called. The only place I see that used outside of tests is from the Pocket addon, which calls that on startup. I don't think the use is necessary any longer, try this patch and see if it addresses the startup issue.
Assignee: nobody → mixedpuppy
Yeah! That appears to get rid of the SocialAPI samples before first paint. Good stuff!
Comment on attachment 8862031 [details] [diff] [review] pockettmp I realize this doesn't address the real problem (blocklist) but it does get rid of something unnecessary at this point that results in blocklist loading.
Attachment #8862031 - Flags: review?(mconley)
Comment on attachment 8862031 [details] [diff] [review] pockettmp Review of attachment 8862031 [details] [diff] [review]: ----------------------------------------------------------------- I can rs=me this - but I'll point out that I've never really poked around in the Pocket code before. :)
Attachment #8862031 - Flags: review?(mconley) → review+
All set here, mixedpuppy? Can we set checkin-needed?
Whiteboard: [photon-performance][qf] → [photon-performance][qf:p1]
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/259ac1fb5cf2 "Load SocialAPI providers lazily". r=mconley
You need to log in before you can comment on or make changes to this bug.