Closed Bug 1359851 Opened 4 years ago Closed 4 years ago

Load SocialAPI providers lazily

Categories

(Firefox Graveyard :: SocialAPI, enhancement, P1)

55 Branch
enhancement

Tracking

(firefox55 fixed)

RESOLVED FIXED
Firefox 55
Tracking Status
firefox55 --- fixed

People

(Reporter: mconley, Assigned: mixedpuppy)

References

(Blocks 1 open bug)

Details

(Whiteboard: [photon-performance][qf:p1])

Attachments

(1 file)

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?
Flags: qe-verify?
Priority: -- → P2
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 :-).
Attached patch pockettmpSplinter Review
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
Flags: needinfo?(mconley)
Status: NEW → ASSIGNED
Priority: P2 → P1
Yeah! That appears to get rid of the SocialAPI samples before first paint. Good stuff!
Flags: needinfo?(mconley)
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?
Flags: needinfo?(mixedpuppy)
Whiteboard: [photon-performance][qf] → [photon-performance][qf:p1]
Flags: needinfo?(mixedpuppy)
Keywords: checkin-needed
Pushed by cbook@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/259ac1fb5cf2
"Load SocialAPI providers lazily". r=mconley
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/259ac1fb5cf2
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 55
Iteration: --- → 55.4 - May 1
Flags: qe-verify? → qe-verify-
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.