(Under OSX) Almost all of it is doing InitialReflow for browser.xul; other pieces are for the hidden window and about:blank, which are insignificant. mshark file of just the InitialReflow for browser.xul attached, 100us sample granularity. The breakdown is roughly: 84.7% InitialReflow 44.9% CSSFrameConstructor::ContentInserted 43.2% CSSFrameConstructor::ProcessChildren 29.4% ConstructFramesFromItemList 13.9% AddFrameConstructionItems 37.2% nsBindingManager::ProcessAttachedQueue 37.2% nsXBLBinding::ExecuteAttachedHandler 19.6% nsXBLProtoImplAnonymousMethod::Execute 17.5% nsXBLBinding::ExecuteAttachedHandler

(In reply to comment #0) > mshark file of just the InitialReflow for browser.xul attached, 100us sample > granularity. Not attached.

Bleh, too big. Will be below in a few min.. (15mb) http://people.mozilla.com/~vladimir/misc/browser-xul-InitialReflow.mshark

General comments: 1) Our browser UI, last I checked, weighs in at about 1.5 times as many DOM nodes as the CNN front page. Mostly anonymous content of bindings bound to anonymous content of bindings bound to actual nodes in the XUL document. Or rather, most of the nodes come in at 2-4 levels of binding nesting, again last I checked. 2) If I look at the total time spent under AddFrameConstructionItems (both from the original insert and from the mutations those XBL constructors perform), it looks like about 66% of the total InitialReflow time. Of this 66%, 93% (so about 60% of the InitialReflow time) is under LoadBindings. Past that, the LoadBindings time is about 50% actually loading and parsing the binding XML and about 50% is compiling prototype members. Summary: "Too much XBL" As far as fixing this, on the platform side we can work on improving performance of the JS compiler, fastloading XBL, etc. On the app/toolkit side, they can try to cut out some of those 4000+ DOM nodes and reduce the size of some of those XBL bindings, as well as the number of methods, properties, etc hanging around. Also, on the app/toolkit side we can consider putting bindings not used by the browser window in separate files from bindings that are (so they don't have to be parsed while parsing the ones we actually care about). We could look into reducing the number of binding files we end up having to load for our browser UI (30 or so, last I checked). But that all would likely only help with that 30% of total time that's parsing the XBL; the JS compilation is happening on bindings we're actually using...

Looping in Neil, since he'll almost certainly be involved in any paring down of the bindings/inheritance chains. I suspect there's a decent amount of fat in menus, they're our biggest set of elements by a long shot, and we haven't trimmed that much.

bug 507526 may help with JS compilation time, though I'm not sure it matters as much when reading from a buffer?

Yeah, don't think it'll help... we're not reading from a FILE *. In fact, doesn't that patch only help in the js shell?