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.

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.

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.

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.