109505 2013-02-11 15:30:16 -0800 The ElementData Refactoring of Glory 2017-03-14 13:14:01 -0700 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 109529 109610 109643 109752 109756 109888 109959 109976 110025 113938 1 kling kling kling koivisto oldest_to_newest 830218 0 kling 2013-02-11 15:30:16 -0800 Some of my ideas for ElementAttributeData: * Class renames: - ElementAttributeData => ElementData - MutableElementAttributeData => PrivateElementData - ImmutableElementAttributeData => SharableElementAttributeData I'm removing "Attribute" from the name since I plan to move non-Attribute things (specifically, the Element's tag name into ElementData.) Private/Sharable are better descriptions of what Mutable/Immutable data really are. * Move ElementData & co into Element.h/cpp. They should really just act as dumb containers for Element, so any logic belongs in there. * Unionize Element::m_tagQName and Element::m_elementData (m_tagQName will be in m_elementData->tagQName if the relevant Node flag is set.) - This could save ~500 KB on the Membuster3 benchmark. - This clever idea (C) Antti. * Replace the three ElementData members for "cooked" versions of the id/class/style attributes by indices. - Let Attribute::m_value be either an AtomicStringImpl* OR one of three special AttributeValue classes (e.g IdAttributeValue, StyleAttributeValue and ClassAttributeValue.) - This could save ~1000 KB on the Membuster3 benchmark. * Make it possible to mutate the attributes in a SharableElementData without turning into a PrivateElementData, assuming it hasOneRef(). - This could save ~800 KB on the Membuster3 benchmark. 1287763 1 kling 2017-03-14 13:14:01 -0700 Let's consider this done. The remaining ideas are too cheesy and the risk:reward ratio does not justify complicating the code any further.