Ehsan Akhgari wrote:
> I have started an effort to gather some information on what options
> we have with regard to using PGO on Windows in the longer term[.]

> If you have ideas
> which are not covered by the bugs on file, please do let me know.

Minimizing startup time is one of the biggest reasons we combine as much as 
possible into libxul. But, if we look at NSPR and NSS, on their own they 
account for 12 separate DLLs, all(?) of which are loaded at startup time.

It should be very, very simple to combine these DLLs together:

    plc4.dll + plds4.dll + nspr4.dll => combined-nspr4.dll
    nss3.dll + ssl3.dll  + smime3.dll => combined-nss3.dll
    softokn3.dll + nssdbm3.dll + freebl3.dll => softokn3.dll

With just a little more work, we could combine things further:

    nssutil3.dll + combined-nspr4.dll => combined-nspr4-and-nssutil3.dll

With just a little work, then, we'd have reduced the number of NSPR and NSS 
DLLs from 12 to 4. That should be a perf win for cold startup (especially on 
spinning rust disks).

If we're willing to spend some of that perf win to solve this problem, then we 
could factor out some of the bottom-most parts of libxul (xpcom/, parts of 
ipc/, parts of netwerk/, maybe parts of security/manager, and other things with 
no/few dependencies) into a separate DLL. We'd have to measure the startup time 
impact very carefully, and the negative impact from the cross-library calls, 
but if we can find enough stuff to throw into that split-off DLL then it might 
be a big enough win to hold us over for a while. Possible negatives: pelocation 
overhead may increase and inter-module inlinining may decrease.

Cheers,
Brian
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to