Open Bug 506416 Opened 15 years ago Updated 2 years ago

nsPresShell::InitialReflow takes ~20% of warm start time

Categories

(Core :: Layout, defect)

x86
macOS
defect

Tracking

()

People

(Reporter: vlad, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [ts])

(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.
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...
Depends on: 94199
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?
blocking1.9.1: needed → ---
Blocks: 447581
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.