Here is a profile of starting the browser toolbox on a local mac build: http://bit.ly/2EG3tyR

I see a few things taking a significant amount of time that don't seem relevant to the browser toolbox:

• starting the add-on manager
• starting telemetry
• (OS X specific) creating the Firefox hidden window, which loads most of the scripts of a normal browser window.

The patch I added here is a quick hack, so not sure if it's really ready for review, but feedback is welcome. Here is a profile with the patch applied: http://bit.ly/2EHJS1v

(In reply to Florian Quèze [:florian] from comment #0)

I see a few things taking a significant amount of time that don't seem relevant to the browser toolbox:

• starting the add-on manager

This is usually around 300ms and tracked via bug 1547139. Currently I'm trying to get around calling into `` when automation is enabled. See bug 1692875. Maybe we could do something similar to the cue check for DevTools connections in browser.js?

• starting telemetry

The telemetry specific part here is mostly all around gfxPlatformMac::CreatePlatformFontList() which in this case is 60ms. Not sure if there is a way around it, or if it could be further reduced for Firefox instances as used by the Multi-Process Browser Toolbox. Jonathan, what do you think?

(In reply to Henrik Skupin (:whimboo) [⌚️UTC+1] from comment #3)

• starting telemetry

The telemetry specific part here is mostly all around gfxPlatformMac::CreatePlatformFontList() which in this case is 60ms. Not sure if there is a way around it, or if it could be further reduced for Firefox instances as used by the Multi-Process Browser Toolbox. Jonathan, what do you think?

In my profile captured yesterday (https://share.firefox.dev/3bdKGMd) for bug 1692875, gfxPlatformMac::CreatePlatformFontList() is 32ms out of 45ms for Telemetry, so avoiding telemetry would still save a bit of time.

It looks like telemetry is triggering the initialization of gfxPlatform there, which is how we reach CreatePlatformFontList() and its 32ms.... but I'm guessing that if we avoid the telemetry, we'll just end up initializing gfxPlatform via some other codepath, so we'll still end up doing much of the same work.

This browser toolbox process runs as a separate "parent" browser process, right? That means it doesn't get the benefit of the shared font-list like content processes do; it has to call CTFontManagerCopyAvailableFontFamilyNames for itself, which is the most expensive thing we're doing here. I don't see any easy way to avoid that, unless the process can get away without using fonts at all.

(In reply to Jonathan Kew (:jfkthame) from comment #5)

This browser toolbox process runs as a separate "parent" browser process, right?

It should be it's own Firefox process with a dedicated and different profile.