Firefox startup performance

[Boris Zbarsky]

Note: followup set to .performance; if you're reading this in .firefox, you
might want to follow there.

I recently did some profiling of Firefox startup. Briefly, a lot of the time is
spent in or under JS (no that suprising). A bunch of time is spent under XBL
code of various sorts.

Which got me and Mike Connor interested in XBL fields (which are not shared,
unlike methods/properties, and are not only compiled but evaluated at binding
instantiation time).

So I did some quick-and-dirty instrumentation of fields with PR_Now() calls at
beginning and end of nsXBLProtoImplField::InstallMember and a printf:

fprintf(stdout, "XBL field: %lld %s %s\n", end - start,
NS_ConvertUTF16toUTF8(mName).get(), bindingURI.get());

If we decide we trust this output, here's what it looks like:

~% sed 's/^XBL field: //' ~/log.txt | sort -n -r
104856 mTabContainer chrome://global/content/bindings/tabbrowser.xml
55218 mTabstrip chrome://global/content/bindings/tabbrowser.xml
38426 _stringBundle chrome://browser/content/search/search.xml
37213 _bundle XStringBundle
35934 tree chrome://global/content/bindings/autocomplete.xml
25452 _scrollButtonUp chrome://global/content/bindings/scrollbox.xml
23394 mTabBox chrome://global/content/bindings/tabbrowser.xml
16526 _textbox chrome://browser/content/search/search.xml

Those are all wall-clock times in microseconds for the fields that took at least
10ms to deal with. For mTabContainer, approximately none of the time is spent
actually finding the node, and lots is spent instantiating its XBL binding.
Same for mTabstrip. Not sure about the other ones yet, esp the XStringBundle
thing (the more so because _bundle is lazily set to the string bundle in
stringbundle.xml, as far as I can tell).

If we are still trusting the output, the total time taken by the tabbrowser
fields is about 210ms. That's out of a 3.5 second total Ts, so about 5-6%.

-Boris