Selector performance regression when parsing XML

[steveworkman]

Related to ​http://bugs.jquery.com/ticket/10377 jQuery 1.7 no longer supports selecting XML nodes by [nodeName='z:row']. The agreed workaround is to use "z
:row, row" as the selector instead.

Running this through larger amounts of data, I'm seeing significant slow-down in IE browsers when using 1.7 compared to using 1.6.4. JSPerf test can be seen here ​http://jsperf.com/node-vs-double-select

Performance appears to have reduced by half in IE8, Opera 12 and Safari 5.1 and by small amounts in other browsers. Chrome and Firefox performance is almost identical.

[dmethvin]

Did you try the custom plugin in the ticket? If you're having performance issues that should be much faster.

[steveworkman]

Replying to dmethvin:

Did you try the custom plugin in the ticket? If you're having performance issues that should be much faster.

I've updated the perf test ​http://jsperf.com/node-vs-double-select with a custom filter-based plugin. It works and is a lot faster, but in order to select the right set in the first place I have to go 8 levels of children() down because filter does not recurse like find does. It is much faster, but:

1. doesn't solve the performance problem in 1.7
2. isn't work-able because I'm having to use multiple .children() calls

[dmethvin]

If you're going that deep, use a filter function passed to .find(). How does that fare?

[steveworkman]

Replying to dmethvin:

If you're going that deep, use a filter function passed to .find(). How does that fare?

Testing the following function:

$.fn.filterNode = function(name) {
      return this.find('*').filter(function() {
        return this.nodeName === name;
      });
    };

I get a very fast selector, in the order of 200x faster than .find('z\\:row, row') and about 5x faster than the .children().children().children().children().children().children().children().filterNode('z:row') function.

Full jsPerf test results are at ​http://jsperf.com/node-vs-double-select/3

Could this one-line plugin be integrated into the selector engine to allow for faster node selection?

[dmethvin]

That's not a very generalized function, so no. Filtering with a function *is* generalized and it does exactly what you want in this case.