Window opening performance
Boris Zbarsky
First of all, we have a problem with it. Ignoring metrics and all that, it's
just slow. Even on pretty modern hardware opening a window shows appreciable
lag. If we look at the metrics,
https://bugzilla.mozilla.org/show_bug.cgi?id=372637 has some numbers from back
in May that show that we're a good bit slower than Firefox 1.5 (and that so is
Firefox 2). We're even slower than Firefox 2, in spite of several Gecko changes
that gave pretty good Txul improvements. Basically, as far as I can tell the UI
is slowing down at about the pace of Moore's Law. This is suboptimal.
I've done some profiles of startup and window open in Firefox, and a lot of time
is spent setting up XBL bindings, and the bindings on the anonymous content of
those bindings, and the bindings on the anonymous content of those bindings, and
so forth. There are several issues here:
* We use <field>s a lot. Unfortunately, <field>s are evaluated at binding
attachment time. If we're not likely to use the value, this is inefficient.
Even if we're likely to use the value, it might be worth delaying the evaluation
somehow. Perhaps we should look into XBL hooking JS property; I assume it's
safe to run JS under there? If so, we could perhaps evaluate fields lazily.
But even as it is, it might possibly be worth it to convert some fields to
properties. It would be even better to just get rid of some fields.
* We use a LOT of elements. Applying the attached patch, the output is:
At depth 0 have 528 elements (non-anonymous stuff only)
At depth 1 have 1582 elements (include directly bound anon content)
At depth 2 have 2641 elements (etc)
At depth 3 have 3450 elements
At depth 4 have 4082 elements
At depth 5 have 4423 elements
At depth 6 have 4552 elements
At depth 7 have 4573 elements
then the numbers stabilize. So not only do we have anonymous content nested
seven levels deep, but we end up with about 4500 elements all told hanging
around. Plus of course all the insertion point info for them, etc etc. No
one's ever accused XBL of being super-efficient. ;) In any case, for scale,
the number of elements for some websites as of today:
msn.com: 718
netscape.com: 1426
google.com: 88
Bug 372637: 1006
Firefox tinderbox: 5404
news.bbc.co.uk: 893
foxnews.com: 837
Ideally, commonly used bindings would use as few elements as possible, with us
introducing core Gecko rendering features (the already-existing
moz-border-colors and moz-border-radius, the being-worked-on moz-border-image,
etc) if necessary to handle eye-candy. That would both reduce memory
consumption and speed up both construction of the DOM and layout. This does
require that all toolkit reviewers keep binding bloat in mind, though...
-Boris