Bug 105540 – CodeGen: Make [Reflect] use fastGetAttribute and fastHasAttribute

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Erik Arvidsson]

Currently the codegen generates code that use getAttribute and hasAttribute. We can use fastGetAttribute and fastHasAttribute when we use a non SVG animated attribute and not HTML::styleAttr.

Performance results:
				With patch				Master 
Bindings/id-getter	runs/s	518.13	± 2.85%	16.17% Better		446.03	± 7.74%
Dromaeo/dom-attr	runs/s	141.68	± 1.72%	20.81% Better		117.27	± 1.47%

[Erik Arvidsson]

Created attachment 180347 [details]
Patch

[Erik Arvidsson]

Created attachment 180349 [details]
Patch

[Andreas Kling]

Comment on attachment 180349 [details]
Patch

r=me, great idea!

Maybe we could also use getIdAttribute()/getNameAttribute() for id/name to avoid iterating over the attribute list in case the attribute isn't present.

[Erik Arvidsson]

(In reply to comment #3)
> (From update of attachment 180349 [details])
> r=me, great idea!
> 
> Maybe we could also use getIdAttribute()/getNameAttribute() for id/name to avoid iterating over the attribute list in case the attribute isn't present.

Good idea. I'll do that next.

I was also considering introducing "fast" versions of the following:

getURLAttribute
getIntegralAttribute
getUnsignedIntegralAttribute

But the benefit might be less obvious since these do a lot of work compared to fastGetAttribute and fastHasAttribute.

[WebKit Review Bot]

Comment on attachment 180349 [details]
Patch

Clearing flags on attachment: 180349

Committed r138263: <http://trac.webkit.org/changeset/138263>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Tony Chang]

I think this is causing svg/custom/animate-reference-crash.html to hit an ASSERT on the debug bots:
http://test-results.appspot.com/dashboards/flakiness_dashboard.html#showExpectations=true&tests=svg%2Fcustom%2Fanimate-reference-crash.html

[Erik Arvidsson]

https://bugs.webkit.org/show_bug.cgi?id=105555

[Eric Seidel (no email)]

Not surprising.  That means that fastAttributeLookupAllowed is doing it's job, and we need to make the generator slightly smarter!

[Erik Arvidsson]

(In reply to comment #9)
> Not surprising.  That means that fastAttributeLookupAllowed is doing it's job, and we need to make the generator slightly smarter!

Yup. The codegen only checks the type and className is a special case where the type is DOMString and not SVGAnimatedString. Maybe we should override it in SVGSVGElement.idl to use the correct type?

[Erik Arvidsson]

(In reply to comment #10)
> (In reply to comment #9)
> > Not surprising.  That means that fastAttributeLookupAllowed is doing it's job, and we need to make the generator slightly smarter!
> 
> Yup. The codegen only checks the type and className is a special case where the type is DOMString and not SVGAnimatedString. Maybe we should override it in SVGSVGElement.idl to use the correct type?

Actually, SVGStylable.idl does override className. Now I'm not sure why we hit the assert.