[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