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%
Created attachment 180347 [details] Patch
Created attachment 180349 [details] Patch
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.
(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.
Comment on attachment 180349 [details] Patch Clearing flags on attachment: 180349 Committed r138263: <http://trac.webkit.org/changeset/138263>
All reviewed patches have been landed. Closing bug.
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
https://bugs.webkit.org/show_bug.cgi?id=105555
Not surprising. That means that fastAttributeLookupAllowed is doing it's job, and we need to make the generator slightly smarter!
(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?
(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.