441355 - Avoid NSS initialization on startup

Status: RESOLVED FIXED

(Core :: General, defect, P3)

Description

[Robert Sayre]

Initializing NSS on startup is i/o heavy and results in tons of syscalls to initialize the various PRNGs etc. My understanding is that the reason we're doing this is for the update service and antiphishing. We should be able to avoid these two cases until after the homepage is up.

Comment 1

[Damon Sicore (:damons)]

Sayre, is this something we can get in 1.9.1?

Comment 2

[Robert Sayre]

I don't know.

Comment 3

[Dave Camp (:dcamp)]

Safebrowsing uses NSS to hash urls during the lookup process.  I don't see any reason why this should require initializing all of NSS, so maybe that initialization could be split out somehow.

Otherwise we'd have to avoid malware checks at startup, which seems like a bad idea.

Comment 4

[Stuart Parmenter]

taras, did you look at this at all?

Comment 5

[(dormant account)]

(In reply to comment #4)
> taras, did you look at this at all?

Briefly, I know it shows up in the fstat log, but I haven't investigated why and what can be done about it in detail. The code did not seem easy to modify I ran for the hills towards easier optimizations.

Comment 6

[Robert Sayre]

It's because it rummages around /tmp looking for "entropy". Graydon would be happy to tell you all about it.

Comment 7

[Graydon Hoare :graydon]

See bug 96058 and bug 338601, and the associated trail of sorrow in bug 322529 ... there are others.

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

The core issue is NSS rummaging around temp files; I don't think we need to avoid initializing NSS at all, but we should use OS-provided randomness for init if it exists, especially on win32.  Doing the temp file trawling is taking > 500ms for me on a cold startup of firefox under win7.

Comment 9

[Brendan Eich [:brendan]]

(In reply to comment #8)
> The core issue is NSS rummaging around temp files; I don't think we need to
> avoid initializing NSS at all, but we should use OS-provided randomness for
> init if it exists, especially on win32.  Doing the temp file trawling is taking
> > 500ms for me on a cold startup of firefox under win7.

Is this not bug 338601 ? It's still open and the last comment's questions (from me) haven't been answered. Please rattle cages there if it's the right bug.

/be

Comment 10

[Brendan Eich [:brendan]]

(In reply to comment #8)
> The core issue is NSS rummaging around temp files; I don't think we need to
> avoid initializing NSS at all,

Some replies to this part of Vlad's comment showed up in bug 501605.

/be

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

When Firefox is launched, one process starts (which, IINM, does profile 
selection).  It then starts a second process which ultimately acts as the 
browser.  In FF 3.5, BOTH processes fully initialize NSS, which means NSS 
gets initialized TWICE before the user's window appears.

It's unclear why NSS needs to be initialized in that first process.  
I suspect that NSS is not actually needed in that first process, and if not
then avoiding the initialization in the process completely will result in 
significant time savings.

Comment 12

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #11)
> When Firefox is launched, one process starts (which, IINM, does profile 
> selection).  It then starts a second process which ultimately acts as the 
> browser.

That's not quite accurate. We will occasionally restart during startup, but only when new components need registering (e.g. after you've installed/updated an extension, first startup of Firefox, etc.). If you're seeing that behavior frequently, that's a bug.

Comment 13

[Nelson Bolyard (seldom reads bugmail)]

If the user has enabled the profile selection dialog at startup (as I do), 
he ALWAYS gets that restart behavior.  

But my observation in comment 11 is based on the procmon logs attached to 
bug 501605.  Maybe its a bug, but users are experiencing it, as shown in 
those logs.

Comment 14

[Dietrich Ayala (:dietrich)]

The software update ping and safebrowsing (per dcamp's earlier comment) both init NSS. Basically, anyone making https connections before first page load should be delayed if at all possible.

Comment 15

[Dietrich Ayala (:dietrich)]

Ryan, can you figure out exactly where NSS is being initialized before BrowserStartup() returns? Once we know that, we can evaluate the actual cost of moving NSS init out of the startup path.

Comment 16

[Ryan Flint [:rflint] (ping via IRC for reviews)]

From what I've seen, we're not initializing NSS until after BrowserStartup() and it's safebrowsing that's doing it (in nsUrlClassifierDBService::Init()). However, we don't fully initialize that until 2s after startup (http://mxr.mozilla.org/mozilla-central/source/browser/components/safebrowsing/content/sb-loader.js#40) - which could impact us if we're still loading content. Ideally we'd do something like comment 3 and split out the hashing algorithms we need.

Comment 17

[Dietrich Ayala (:dietrich)]

When does the first software update ping occur? Maybe that's what the reporter and Nelson were seeing? How about if a user is restoring a session with an https page?

Comment 18

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 24 weeks.

Comment 19

[Florian Quèze [:florian]]

As part of photon-performance, we landed several fixes (bug 1362364, bug 1367450, bug 1359031, bug 1337043) to delay NSS init until after first paint. It's now triggered during delayedStartup by captive portal detection.

It would still be better if we could init NSS off main thread (bug 1370516), but I think the changes landed in 57 are enough to call this very old bug fixed.