922053 - Peacekeeper domJQueryBasics slower than in Chrome

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Jan de Mooij [:jandem]]

Attachment: Testcase

Original test here: http://www.peacekeeper.therichins.net/test20.html Attaching a stand-alone version with non-minified jQuery (same version, 1.6.4).

Numbers:

Chrome 31:  1851 ms
Nightly 27: 3840 ms

Test does just this:

    $("#chosenOne");
    $("div");
    $(".title");
    $("*", document.body);
    $("div.title:nth-child(1)");

bz: filing as a DOM bug because I see some time under SelectorMatches but there's also time in JS.

Comment 1

[Boris Zbarsky [:bzbarsky]]

So what I see is about 53% of the time in JS stuff of various sorts.  Then:

* 30% under DOM Element methods (23% querySelectorAll, 4% setAtrtibute,
                                 2.5% removeAttribute)
* 8% under document.querySelectorAll()
* some time doing array_slice on nodelists calling into
  NodeListBinding/HTMLCollectionBinding::DOMProxyHandler::getElementIfPresent, 
* 4% getting props on document (ending up in the documentElement getter, looks like, but
  about 3% of this or more is JS engine braindamage not being able to optimize DOM stuff
  on a proxy, afaict).

The actual querySelector calls are doing lots of AttrCount(), nsAttrValue::Equals(), nsAttrAndChildArray::GetAttr(), Element::GetAttrCount(), all under SelectorMatches.  That's a bit odd..

Everything other than that bit on the DOM side is covered by existing bugs, I believe; we just need to set dependencies.  The JS bit here needs investigation.

Comment 2

[Boris Zbarsky [:bzbarsky]]

OK.  So the attr bits are a result of the jquery code for $("*", document.body); constructing the selector "[id=something] *", setting id="something" on document.body, and then running that selector.  That kinda sucks.  :(

Actually setting up the ancestor filter here would not help any, since in fact everything _does_ match.  We could try to make the attr-selector-matching bit faster somehow.  note that this can win us at most 500ms from the numbers in comment 0, even if we magically made _all_ the time under SelectorMatchesTree go away.  :(  The contribution of the JS bits is much higher than that.

Unfortunately, that [id=something] code is still out there in the real jQuery, so it might be worth a separate bug on that part...

Comment 3

[Jan de Mooij [:jandem]]

Time for each of these selectors (Nightly 27 / Chrome 31):

$("#chosenOne")                 45 /  17 ms (2.6x slower)
$("div")                       586 / 344 ms (1.7x slower)
$(".title")                    595 / 164 ms (3.6x slower)
$("*", document.body)         2244 / 940 ms (2.4x slower)
$("div.title:nth-child(1)")    439 / 320 ms (1.4x slower)

Note that the 4th one is like 60% of the total time. The .title selector is the only one where we're > 3x slower than Chrome.

Comment 4

[Jan de Mooij [:jandem]]

(In reply to Jan de Mooij [:jandem] from comment #3)
> 
> $(".title")                    595 / 164 ms (3.6x slower)
> 
> The .title selector is the only one where we're > 3x slower than Chrome.

Oops, I must have messed something up. Now that I'm remeasuring it's more like

$(".title")                    214 / 164 ms (1.3x slower)

Much better.

Comment 5

[Jan de Mooij [:jandem]]

The Sizzle function (where the complicated selectors end up) is not Ion-compiled because it has a try-finally block. Compiling try-finally (bug 885514) should win a few %.

Looking at jQuery 2.0.3, the finally block is still there.

(Yes, before bug 866878 code like this always ran in the interpreter...)

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Nightly 2800ms vs Chromium 3300ms on 64 bit Linux.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Need to test this on Windows.

Comment 8

[Guilherme Lima]

Windows 7

On the testcase
Firefox 31 - 3739 ms
Chrome 36 - 5036 ms

On the Peacekeeper test
Firefox 31 - 1958 op/s
Chrome 36 - 1670 op/s

Similar results on Nightly.