673261 - Determine impact of NSS on startup

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect)

Description

[Benjamin Stover (:stechz)]

It is suspected that NSS does some sqlite and other file i/o on startup. Perhaps we could delay the initialization of NSS if this is the case.

Comment 1

[(inactive) Jim Chen [:jchen] [:darchons]]

FWIW, when I was troubleshooting sqlite breakage with clang, I saw sqlite used by NSS only _after_ we are already on the home page (presumably NSS loads when loading the list of addons on the home page)

In comparison, the permissions, addons, etc. sqlite db all loaded during startup, before home page.

Comment 2

[Benjamin Stover (:stechz)]

Metabug 673253 lists some patches that delay all SQlite usage until after first paint. The permissions is a platform issue, addons/etc. are all Fennec's fault.

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #2)
> Metabug 673253 lists some patches that delay all SQlite usage until after
> first paint. The permissions is a platform issue, addons/etc. are all
> Fennec's fault.

Fennec tries hard to not willingly use NSS during startup. We cache the list of recommended add-ons so we don't need to use a HTTPS AMO service API. We convert HTTPS -> HTTP for the add-on favicons (which has led to bug 669982). If we have no add-on cache, we wait 6 seconds after the first page has loaded before requesting the list from AMO.

Comment 4

[Benjamin Stover (:stechz)]

Closing this since NSS hasn't been showing up in startup.

Comment 5

[Mike Hommey [:glandium]]

(In reply to comment #4)
> Closing this since NSS hasn't been showing up in startup.

We're still loading it and are forced to load it. We should try to delay that. Requires making PSM a component, making binary components work in the apk and stop loading nss manually at startup.

Comment 6

[Benjamin Stover (:stechz)]

Let's reopen then. I don't know if there's an impact from starting and stopping it, but it's worth looking into.

Comment 7

[Mike Hommey [:glandium]]

(In reply to comment #6)
> Let's reopen then. I don't know if there's an impact from starting and
> stopping it, but it's worth looking into.

There's the overhead of uncompressing and dlopen()ing it, I think that looks like 100ms overall. I'll get actual numbers.

Comment 8

[Benjamin Stover (:stechz)]

Oh, is NSS not built into libxul?

Comment 9

[Mike Hommey [:glandium]]

It's hard to get reliable numbers on Android, but it looks like it would be around 100ms saved on cold cache extracted libs, 50ms on warm cache extracted libs and 150ms on cold cache no extracted libs. These numbers only account Android dynamic linker time, not anything else. I got these numbers from a build with PSM completely disabled (not even built), which also appears to fail to work properly (no content showing up, no way to type anything in the url bar)

So making PSM a component again and delaying its loading looks like a worthwhile goal.

Comment 10

[BMO Automation]

Closing all opened bug in a graveyard component