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.
Sayre, is this something we can get in 1.9.1?
I don't know.
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.
taras, did you look at this at all?
(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.
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.
(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.
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.
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.
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.
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?