724059 - Link NSS shared libraries to Firefox.exe so operating system can better optimize loading them

Status: RESOLVED WONTFIX

(Core :: Security: PSM, enhancement)

Description

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

+++ This bug was initially created as a clone of Bug #711032 +++
+++ This bug was initially created as a clone of Bug #711014 +++

(In reply to Sean Leonard from bug 711014 comment 2)
> Much to my surprise, firefox.exe (Firefox 9.0.1) only dynamically links to
> kernel32.dll, user32.dll, and msvcr80.dll. Mac OS X: firefox-bin only links
> to libmozutils.dylib, libstdc++.6.dylib, and the standard Mac OS X
> frameworks (Cocoa, Exceptionhandling, CoreFoundation, libSystem.B.dylib).

Comment 1

[(dormant account)]

Can you elaborate on "so operating system can better optimize loading them"? do you have any numbers to support enhancement?

Comment 2

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

It was actually bug 711032 comment 2, which also included this comment:
> This could be a performance problem. If the Firefox executable linked
> (for example) to nss3.dll, nspr4.dll, xpcom.dll, and so forth, OS
> components could figure out how to lay out the memory much faster,
> and could precompute the runtime loader tables.

Comment 3

[(dormant account)]

(In reply to Brian Smith (:bsmith) from comment #2)
> It was actually bug 711032 comment 2, which also included this comment:
> > This could be a performance problem. If the Firefox executable linked
> > (for example) to nss3.dll, nspr4.dll, xpcom.dll, and so forth, OS
> > components could figure out how to lay out the memory much faster,
> > and could precompute the runtime loader tables.

we do this so we can use readahead to load xul.dll. This cuts down xul.dll loading time by a second or a more. Overhead you are describing is irrelevant in comparison.