If we remove support for Attr nodes in the DOM, we could save 3 words per attribute, as follows:
1) Remove the Attr pointer from Attribute. (one word for the pointer)
2) Make Attribute not be refcounted any more. (one word for the refcount)
3) Change NamedAttrMap to hold a Vector<Attribute> instead of Vector<RefPtr<Attribute> > (one word for the pointer in the vector.
There could be additional savings from reducing fragmentation.
Other browsers do not support Attr nodes and have stated they do not plan to support them and would like them removed from standards, so it should not be a compatibility risk to do this.
Removing Attr node support may break XPath pretty badly (I haven't looked into XPath implementation again to be sure, but I think that many practical cases depend on Attr nodes being supported).
(In reply to comment #1)
> Removing Attr node support may break XPath pretty badly (I haven't looked into
> XPath implementation again to be sure, but I think that many practical cases
> depend on Attr nodes being supported).
Can you expand on this? Does this break functionality in Firefox?
I just remember that XPath was pretty big on creating Attr nodes from attributes, which is why I had to optimize that code path. If anything breaks, tests will tell.
I'm not sure how what Firefox has to do with this - it's just an implementation detail of XPath, it can certainly be special-cased to use custom attribute values instead of Attr nodes internally.
(In reply to comment #0)
> Other browsers do not support Attr nodes
In both Opera and Firefox 3, I'm getting the same Attr node when calling getAttributeNode() twice in a row, so it seems that they are referenced in DOM. What is the difference from WebKit in their Attr node support?
As discussed on IRC, this bug is not valid, because other browsers do support Attr nodes. It may be possible to make use of the fact that these nodes are rarely used though.
Mass moving XML DOM bugs to the "DOM" Component.