105065 - move mListenerManager from XUL element into slots

Status: RESOLVED WONTFIX

(Core :: XUL, defect, P3)

Description

[Chris Waterson]

I should really measure this first, but...

I'd guess that most XUL elements do _not_ have event handlers, and so we could
reduce the size of the XUL element and see a net win in overall footprint by
moving the mListenerManager field into the lazily-allocated nsXULElement::Slots
structure.

This saves one word per nsXULElement, but penalizes a XUL element that would
have not otherwise been faulted by ~8 words (we're going to get rid of some of
the slot's fields eventually) plus malloc overhead, so say ten words overall.
So, if less than one in ten XUL elements has an event handler, this should be a
net win.

Comment 1

[Chris Waterson]

Actually, one in ten is pretty conservative. I should say, if less than one in
ten _otherwise unfaulted_ XUL elements has an event handler, then this should be
a win.

Comment 2

[David Hyatt]

Hard to say actually.  A lot of XUL elements *do* have event handlers, since the
default event handling behavior for XBL-ified widgets is hooked up by XBL using
the DOM.

Comment 3

[Chris Waterson]

Okay, some quick n' dirty stats. Brought up a couple browser windows, mailnews,
mail compose, bookmarks. There were 9480 XUL elements created, 5247 of which
were heavyweight (i.e., had slots allocated). There were 1026 ELMs created on
heavyweight elements, and 2855 ELMs created on lightweight elements.

So, if we moved mEventListenerManager to the nsXULElement::Slots, we'd fault an
additional 2855 lightweights, driving our heavyweight count up to 5247 + 2855 =
8102.

Assuming that a XUL element is ``currently'' 7 words of data (mPrototype,
mDocument, mParent, mChildren -- converted to nsCheapVoidArray,
mListenerManager, mBindingParent, and mSlots; we get rid of mContentID and
mLazyState in other bugs), and 4 words of vtable (we get rid of
nsIChromeEventHandler in another bug), that gives us 11 words per nsXULElement. 

The Slots are ``currently'' 4 words (including mNameSpace, mNodeInfo,
mAttributes, and mContentID: this assumes we can get rid of mElement and
mBroadcasterListeners by moving the broadcasters to the document; mControllers
the same way, mInnerXULElement by eliminating aggregation).

So, ``currently'', we have

  9480 * 11 + 5247 * 4 = 125268 words of requested heap

If we move the mEventListenerManager to slots, we'll have

  9480 * 10 + 8102 * 5 = 135310 words of requested heap


Bottom line, looks like a net loss. WONTFIX.