length() method is called in each iteration in the for loop in dom (DOMImplementation.cpp, ElementData.cpp, EventContext.cpp), similarly to https://bugs.webkit.org/show_bug.cgi?id=125916
Created attachment 220435 [details] Patch
Comment on attachment 220435 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=220435&action=review > Source/WebCore/ChangeLog:8 > + Do not call length() in each iteration. How did you measure that this improved performance? Could you please post the numbers?
No measurements performed, just omit some unnecessary method calls. I see a possible problem here only when the length is changed within the loop.
Created attachment 223955 [details] Patch
I ran several DOM performance tests on efl, but from this data I cant draw conclusions about the performance of the patch. In fact, at 1 place of the 4 places updated in this patch, the length() method call is meantime moved outside the loop: http://trac.webkit.org/changeset/162394/trunk/Source/WebCore/dom/ElementData.cpp So the patch is updated to cope with the remaining three places.
Comment on attachment 223955 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=223955&action=review > Source/WebCore/dom/ElementData.cpp:146 > m_attributeVector.uncheckedAppend(other.m_attributeArray[i]); Honestly this would probably be better as a new C++11 loop.
Created attachment 225058 [details] Patch
Thanks for the feedback, I tried the following code: for (const Attribute& i : other.m_attributeArray) m_attributeVector.uncheckedAppend(i); Unfortunately m_attributeArray is defined as a zero size array (ShareableElementData.h: Attribute m_attributeArray[0];), so the range based loop does not iterate through it. There is a minor change in the patch to use the stored value in reserveCapacity().
Comment on attachment 225058 [details] Patch Clearing flags on attachment: 225058 Committed r164981: <http://trac.webkit.org/changeset/164981>
All reviewed patches have been landed. Closing bug.