Bug 109505 - The ElementData Refactoring of Glory
Summary: The ElementData Refactoring of Glory
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Andreas Kling
URL:
Keywords:
Depends on: 109529 109610 109643 109752 109756 109888 109959 109976 110025 113938
Blocks:
  Show dependency treegraph
 
Reported: 2013-02-11 15:30 PST by Andreas Kling
Modified: 2017-03-14 13:14 PDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Kling 2013-02-11 15:30:16 PST
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.
Comment 1 Andreas Kling 2017-03-14 13:14:01 PDT
Let's consider this done. The remaining ideas are too cheesy and the risk:reward ratio does not justify complicating the code any further.