Voyeur performance issue

[nevf]

@nbubna Thanks for forking voyeur.js. I'm curious to know whether you have done anything about the Voyeur performance issue.

[nbubna]

Yeah, read my comments on the issue and see the jsperf. Voyeur was defining things every time it touched a node. It was also not doing any caching of the filtered lists. Resolving both problems put the performance within reasonable margin of jQuery and better than Dojo. Further improvements could be made, but probably won't as i don't believe they are worth it. I explain that in the comments.

[nevf]

@nbubna Where are the comments you refer to, I've not been able to find them. Link please.

[nbubna]

It's link at the end of the issue description above: adriancooney#20

Specifically: adriancooney#20 (comment)
http://jsperf.com/voyeur8000/5

[nevf]

@nbubna Thanks, got it. FYI the jsperf has an error:

Script error..

message: Script error.
fileName:
lineNumber: 0

and the HTML test displays 'ERROR'.

[nbubna]

Argh. Something in the page is using AMD, so the "all" version was failing when alter.js started looking for window.HTML. Universal module definition is a pain for a modular build. I'll have to rethink that...

[nbubna]

Here's a fixed version. http://jsperf.com/voyeur8000/11

This one is actually a better profile of HTML's performance, despite the slower result than before, because the latest version does peek into kids of the first element. So selecting an element with children is slightly slower than one without kids.

[nevf]

Thanks for the fix.

[jtenner]

I see the performance, and it's interesting to see that vanilla.js wins on performance.

Offsetting some of the searching by using getElementsByClassName is VERY fast.