document.querySelectorAll sluggish on Firefox (v30) for large DOM

[jcmoore]

On Firefox v30, the platform.js "wrapped" versions of querySelectorAll, getElementsByClassName, getElementsByTagName, and getElementsByName take much longer to execute than their "unwrapped" counterparts.

Example page can be found here -- https://gist.github.com/jcmoore/44b117ce6cd6ab4630f3

[arv]

This is an unfortunate consequence of how we do the ShadowDOM polyfill.

What is worse is that we cannot do live node lists so getElementsByClassName, getElementsByTagName and getElementsByName traverse the whole document instead of exiting when first element is found.

[jcmoore]

Thank you for the swift response @arv . Admittedly, my understanding of all of the inner-workings of platform.js is naive at best, but any chance you (or someone) can elaborate on why the wrapped NodeLists are built from the bottom-up (by javascript tree traversal), instead of from the top-down (by filtering native NodeLists generated by calls to the native querying methods)?

I have an example that seems to work well in Firefox here -- https://gist.github.com/jcmoore/69a49f887e03c1d2bfa1

specifically, please see:
https://gist.github.com/jcmoore/69a49f887e03c1d2bfa1#file-queryselector-js-L11-L40
https://gist.github.com/jcmoore/69a49f887e03c1d2bfa1#file-queryselector-js-L110-L115

and likewise changes to the other overridden query functions:
https://gist.github.com/jcmoore/69a49f887e03c1d2bfa1#file-queryselector-js-L100-L105
https://gist.github.com/jcmoore/69a49f887e03c1d2bfa1#file-queryselector-js-L123-L128
https://gist.github.com/jcmoore/69a49f887e03c1d2bfa1#file-queryselector-js-L146-L151

From platform.js' perspective, do the overridden query methods have to do anything beyond keeping "ShadowDOM" elements out of the resulting (wrapped) NodeLists? Is there something else I'm missing?

Thanks in advance,

[arv]

That is a great approach. I don't see any problems with it and it should add a much needed boost.

At one point we didn't have the treeScope_ so a full walk up the tree would have been required.

We have open bugs on supporting :shadow and other new selectors here but we can special case them.

Do you mind sending a PR?

[jcmoore]

Sure thing, but it may take a little while (as I need to get authorization from my employer to agree on the CLA...)

[arv]

I thought of a problem with using this approach.

<a>
  <b></b>
</a>

var a = ...
var sr = a.createShadowRoot();
sr.innerHTML = 'no content element';
assert.equal(a.firstElementChild, a.querySelector('b'));

The problem is that <b> is not in the composed tree since <a> does not have a <content>.

We might still want to do this even though it breaks a few edge cases. The current solution breaks a few other cases (like 'a > b' when b is composed into some other parent).

@jmesserly

[arv]

@jcmoore You can disable the tests but we do not want to commit breaking tests.

[ebidel]

This is awesome @jcmoore. It would be killer to have some before and after numbers to point people to when all of this lands.

[sorvell]

@ebidel This has now been integrated (yay!) and it sounds like we can close the issue. Leaving it open for you to review since you asked for some data.

[ebidel]

Anyone have decent numbers to share? If not we can close. I just thought it would be great to show perf progress.