The default bug view has changed. See this FAQ.

Avoid NSS initialization on startup

NEW
Assigned to

Status

()

Core
General
P1
normal
9 years ago
3 years ago

People

(Reporter: Robert Sayre, Assigned: rflint)

Tracking

(Blocks: 1 bug, {mobile, perf})

Trunk
mobile, perf
Points:
---
Dependency tree / graph
Bug Flags:
wanted1.9.2 +
wanted1.9.1 -

Firefox Tracking Flags

(status1.9.1 wanted)

Details

(Whiteboard: [ts])

(Reporter)

Description

9 years ago
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.
(Reporter)

Updated

9 years ago
Depends on: 440766
(Reporter)

Updated

9 years ago
Whiteboard: startup
(Reporter)

Updated

9 years ago
OS: Mac OS X → All

Updated

9 years ago
Flags: wanted1.9.1?
Hardware: PC → All
Version: unspecified → Trunk
Sayre, is this something we can get in 1.9.1?

Updated

9 years ago
Keywords: mobile
(Reporter)

Comment 2

9 years ago
I don't know.

Comment 3

9 years ago
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.
No longer depends on: 440766
(Reporter)

Updated

9 years ago
Blocks: 447581

Updated

9 years ago
Assignee: nobody → tglek

Comment 4

8 years ago
taras, did you look at this at all?

Comment 5

8 years ago
(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.
(Reporter)

Comment 6

8 years ago
It's because it rummages around /tmp looking for "entropy". Graydon would be happy to tell you all about it.
See bug 96058 and bug 338601, and the associated trail of sorrow in bug 322529 ... there are others.
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.
Flags: wanted1.9.2+
Flags: wanted1.9.1?
Flags: wanted1.9.1.x+
Flags: wanted1.9.1-
(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
(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
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.
(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.
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.
Keywords: perf
Whiteboard: startup → startup [ts]
status1.9.1: --- → wanted
Flags: wanted1.9.1.x+
Depends on: 462807

Updated

8 years ago
Assignee: tglek → nobody
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.
Priority: -- → P1
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.
Assignee: nobody → rflint
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.
Assignee: rflint → nobody
Assignee: nobody → rflint
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?
Whiteboard: startup [ts] → [ts]
You need to log in before you can comment on or make changes to this bug.