[webkit-reviews] review requested: [Bug 13021] XPath can be very
slow : [Attachment 13617] partial fix 2
bugzilla-request-daemon at macosforge.org
bugzilla-request-daemon at macosforge.org
Tue Mar 13 13:35:25 PDT 2007
Alexey Proskuryakov <ap at webkit.org> has asked for review:
Bug 13021: XPath can be very slow
http://bugs.webkit.org/show_bug.cgi?id=13021
Attachment 13617: partial fix 2
http://bugs.webkit.org/attachment.cgi?id=13617&action=edit
------- Additional Comments from Alexey Proskuryakov <ap at webkit.org>
This brings us almost on par with Firefox (16ms vs. 17ms on my G4, down from
48ms). But it comes with a number of comments:
1) I do not like short-circuiting appendChild() like this, it would be much
better to just make it fast. However, that's definitely not a stabilization
period work (and even changes in Attr.cpp look questionable in this regard).
2) Merging nodesInAxis and nodeMatches saved 24ms, and short-circuiting
appendChild saved another 7ms.
3) However, only making the second change (short-circuiting appendChild)
actually made the performance worse (by 4ms)! I can only guess why that
happened - and my guess is that XPath evaluation creates a lot of memory
fragmentation, causing weird effects with fastMalloc.
4) Running the test for the second time gives a noticeably worse result (24ms).
Again, I can only blame fastMalloc, but without much evidence.
5) There are still a lot of attack vectors for improving performance in this
test. For example, I really want to make NodeVector a Vector<Node*> instead of
Vector<RefPtr<Node> >. Also, "@class" really needs to use getAttributeNode()
instead of enumerating (and instantiating in DOM) all attributes.
More information about the webkit-reviews
mailing list