1359851 - Load SocialAPI providers lazily

Status: RESOLVED FIXED

(Firefox Graveyard :: SocialAPI, enhancement, P1)

Description

[Mike Conley (:mconley) (:⚙️)]

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?

Comment 1

[Shane Caraveo (:mixedpuppy)]

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.

Comment 2

[Florian Quèze [:florian]]

(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 :-).

Comment 3

[Shane Caraveo (:mixedpuppy)]

Attachment: pockettmp

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.

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Yeah! That appears to get rid of the SocialAPI samples before first paint. Good stuff!

Comment 5

[Shane Caraveo (:mixedpuppy)]

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.

Comment 6

[Mike Conley (: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. :)

Comment 7

[Mike Conley (:mconley) (:⚙️)]

All set here, mixedpuppy? Can we set checkin-needed?

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/259ac1fb5cf2
"Load SocialAPI providers lazily". r=mconley

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/259ac1fb5cf2