~100ms regression in cold main time to first frame (1/28; Nimbus FML?)

[mcomella]

Caught in our nightly backfill:

We go from 1.468s to 1.570s (102ms).

┆Issue is synchronized with this Jira Task

[mcomella]

Bisection:

• 1/27 (unaffected) bfa8d85
• 1/28 (affected) 82a6f8c

Possible regressing commits:

$ git log bfa8d85bd..82a6f8cae --pretty=oneline 
82a6f8cae411603ba5abced3b13fc43ca40f335e First use of Nimbus FML plugin (#23400)
e92fe26df74f22c530186d52cf66439b94ce99c3 Import l10n.
15d8ca86d94c7736ace16226f01148afcce3e5df For #23448 - Update the address bar color to use @color/fx_mobile_layer_color_3
6596f4c28b619a42b27e50443636d02ea5e7c96e For #23432 - Use the imageUrl as the favicon for a provided top site

[mcomella]

Continued bisection: the regression appears to be from 82a6f8c #23400.

• e92fe26 (i.e. commit before below) 1373ms local build
• 82a6f8c 1501ms local build

[mcomella]

@jhugman Do you know what may have caused this start up regression in #23400?

[jhugman]

Eyeballing the code, this looks like a re-organization of the code to look up the default browser.

BrowserCache.all(context).isFirefoxDefaultBrowser

causes a lookup of the packageManager, which we've seen causing perf problems before.

        val resolveInfo = packageManager.resolveActivity(intent, PackageManager.MATCH_DEFAULT_ONLY)
            ?: return null

The short term fix is to re-order the code to what it was before. The long term fix is to ensure that isFirefoxDefaultBrowser isn't called from the UI thread.

I'll put up a PR shortly.

[mcomella]

I'm sorry – I should have provided profiles. Here is with the Firefox Profiler (starts around when Gecko starts in start up, low overhead):

• Unaffected: https://share.firefox.dev/3gnR1Gp
• Affected: https://share.firefox.dev/3L6waFO

Here is with the Debug API (starts earlier during start up but has non-trivial overhead):

• Unaffected: https://share.firefox.dev/3IZv5xz
• Affected: https://share.firefox.dev/3Lazujp

I don't see anything obvious.