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
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
