522967 - document.evaluate Performance

Status: NEW

(Core :: XSLT, defect)

Description

[Clint Priest]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) FirePHP/0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) FirePHP/0.3

This is a performance test case for the document.evaluate() function in FF.  This isn't horrible performance as compared to Chrome but if the performance can be improved that would be great as I run into this a lot with my JS programming.

  Chrome - 3 x 1000 = 17431ms
FF 3.5.3 - 3 x 1000 = 32193ms

http://http://www.clintpriest.com/TestCases/FF_353_DOMSpeed3.php

Details of Test Case:
This test case demonstrates performance issues I run into regularly with XPaths.

This code uses the prototype librarys' .down() function.

If you have firebug installed I have enabled profiling of the slowest section which ends up being a call to _getElementsByXPath(), the code for this section is just below.

document._getElementsByXPath = function(expression, parentElement) {
	var results = [];
	var query = document.evaluate(expression, $(parentElement) || document, null,
		XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);
	for (var i = 0, length = query.snapshotLength; i < length; i++)
		results.push(Element.extend(query.snapshotItem(i)));
	return results;
}; 
		
Most of this function is pretty easy on performance; the one call to document.evaluate(), I assume, is the culprit of the performance.

While this problem can be remedied in other ways, it is much easier to use the .down() function (as it ignores text nodes and uses CSS selectors, a major convenience).


Reproducible: Always

Steps to Reproduce:
1. Go to http://http://www.clintpriest.com/TestCases/FF_353_DOMSpeed3.php
2. Click 'Run Test'
3.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Two notes not entirely related directly to this bug:

1)  Over here, Firefox trunk ends up at about 18s, while Chrome is at 17s.  Fx
    3.5.3 is 20s.
2)  If prototype.js were using querySelectorAll instead of xpath, it'd be much
    faster in both browsers.

Profiling the actual testcase, 80% of the time is under nsXPathEvaluator::Evaluate, and another 8% is under under all the SnapshotItem calls.  Another 8% is in js_Interpret.  This stuff seems to not trace because of bug 517143.

In any case, for that 80% part, it seems like there's a lot of LocationStep::fromDescendants going on there (recursion 8 levels deep within that function).  Is that expected in this case?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Oh, and I'm seeing a huge amount of deallocation going on in txResultRecycler::getStringResult, under SetLength calls on strings and ShrinkCapacity on nsTArray (10% of total testcase time is in free() called from those two things!).  Is _that_ expected?

Comment 3

[Clint Priest]

Boris, not sure if you're asking me if those are expected results.  I don't know what would be expected.  All I'm doing with the testcase is getting the results of "TD A" CSS Selector on each item row, x 1000 rows.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Clint, I was asking Peter and Jonas, since they're the experts on the XPath code.  Sorry to not make that clearer.

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

See bug 520621 and bug 520671

Comment 6

[Boris Zbarsky [:bzbarsky]]

Ah, yes.  That covers a lot of what I see, other than the somewhat unexpected level of nesting of fromDescendants.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Attachment: JS file for the testcase

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase without the shark calls

Comment 10

[Boris Zbarsky [:bzbarsky]]

Once bug 499201 lands I should re-profile the querySelector version of this.