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