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]
Comment on attachment 220435 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=220435&action=review
> + 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]
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]
View in context: https://bugs.webkit.org/attachment.cgi?id=223955&action=review
Honestly this would probably be better as a new C++11 loop.
Created attachment 225058 [details]
Thanks for the feedback, I tried the following code:
for (const Attribute& i : other.m_attributeArray)
Unfortunately m_attributeArray is defined as a zero size array (ShareableElementData.h: Attribute m_attributeArray;), 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]
Clearing flags on attachment: 225058
Committed r164981: <http://trac.webkit.org/changeset/164981>
All reviewed patches have been landed. Closing bug.