Fundamental performance issue.

[adriancooney]

Voyeur's performance is bad. It's so bad that Voyeur should never be used in production. It's manages just over 11,000 operations per second on it's most basic traversal in comparison to jQuery's 300,000 operations per second.

The problem is not something I can fix (without changing Voyeur's core values), it's got to do with Object.defineProperty's performance which is absolutely shit. Here is the performance difference of just setting the children's to a property on a node instead of an Object.defineProperty getter function. __defineGetter__ returns similar results.

The way I see it, I have two options.

1. Change the syntax.
   I feel the whole appeal of Voyeur is it's syntax. From the feedback I received, the ability to traverse the DOM like a Javascript object really seemed to resonate with developers so taking this option would defeat the purpose of Voyeur.
2. Freeze the project until the performance is acceptable.
   This may seem like a cop out but I can see no other option that will allow Voyeur to maintain it's uniqueness. I'm not the only one who has noticed the Object.defineProperty performance so I think putting the project on a halt until the various engine's catch up and the performance of Voyeur is satisfactory is the right way to go.

I'm going to go with option 2. I have left a visible warning on the README. Voyeur can be used for trivial projects and in the console but it should never used in production, under any circumstances.

I hope this message doesn't come across as spiteful or sour, that's completely unintentional. Sorry guys.

Comments and suggestions welcome!

[maxov]

One thing that might be possible is a compromise: retain the dot-syntax for transversing the DOM(where most of the cruft is saved), but retain a jQuery-esque API for actually manipulating DOM nodes. This way we can build a tree of objects separate from the DOM without using Object.defineProperty and possibly even get slightly higher performance for some simple queries(nesting) vs jQuery selectors. Here's what I mean(took this from the example):

Voyeur.div.header.h1.em.a.href = "http://google.com" // becomes ->
Voyeur.div.header.h1.em.a.href("http://google.com")
// now we can have these methods separate from the DOM objects

Voyeur("#title").em.a.innerText("New title!")
// .find can be replaced with a functiont(or not, this is a really small thing)

// .use is essentially the same
Voyeur.div.section.ul.li.use(function(li, i) {
    li.a.innerText("Link #" + i)
});

Voyeur.div.section.ul.li.eq(3).classList.add("Highlighted!")

I hope by this point you get what I mean. We have the brevity of Voyeur mixed with the speed of jQuery. And the concept of traversing the DOM with property access(amazing!!!!) is the same. If you think this goes against the project philosophy(which, it kind of seems like it does), that's fine, I'll write a fork or something and benchmark it.

[nbubna]

Does DOM traversal/selection really happen often enough to be a bottleneck? Even when it is, shouldn't caching results (e.g. var divs = HTML.find('#foo').div;) help reduce repetition considerably? Also, jQuery's selection usually happens in native code via querySelectorAll, so for deep traversal with Voyeur (Voyeur.div.div.div.div) you are doing a lot more work along the way than Voyeur.find('div div div div'). So when performance matters, use find() and cache results, when it doesn't feel free to walk the DOM down.

Apart from smarter use of Voyeur's features, i wonder if it is really Object.defineProperty that is so slow or if it is the fact that Voyeur's technique relies upon a "lookahead" at the children of each node it prepares for use. When jQuery wraps node(s), it's cheap because it merely wraps them in a new object with a rich prototype and does no action upon the node itself. Voyeur, however, must immediately map the children out as new properties. Using the getter, it avoids traversing the whole tree, but still, looping over the children of a node will always be much slower than simply wrapping it in an object.

I guess, i'm not so sure that even improved native defineProperty performance will help Voyeur much. But of course, i'm also far from convinced that this is a performance critical feature. I can't think of a use-case where so much traversal/selection would happen that it would really matter which technique was used, even on mobile. And when it does matter, there are workarounds or other libraries. I think it is an overreaction to freeze Voyeur development simply because it fails to match jQuery performance.

And, for that matter, i've not frozen my work on it. In fact, i've taken it pretty damn far in my fork (http://nbubna.github.io/HTML). At this point, it's a competitor and total rewrite (except the gh-pages branch, which still has much in common), but i think you'll be encouraged by where the technique can go. I think it is time to ditch DOM wrappers like jQuery and start working with the DOM directly. Cutting out lots of wrapping API saves a lot of KB, and what i've managed with my each() function is lots of fun. :)

[tomByrer]

http://jsperf.com/voyeur8000/3 incase someone wants to test the performance themselves.

[nbubna]

That getElementsByClassName is so much faster it makes the results of the rest hard to read, and the rest is the comparison i'm most interested in. So, i give you: http://jsperf.com/voyeur8000/5

Looks like i managed to speed things up in my fork!

[nbubna]

Been poking around jQuery to see how they get their speed at this task. It looks like they get it on the simple selector by identifying that they can use getElementsByClassName(). Clever, though i'm still not convinced that selection is a bottleneck that deserves much code/complexity to get a few extra thousand selections per second. Would love to hear about a use-case that proves me wrong, of course. :)

[tomByrer]

I was hoping you'd throw your version in the fray Nathan! Congrats on the speedups!
Seems to break on IE8 (still 8% overall, but some have higher use %).

Would love to hear about a use-case [for faster speed] that proves me wrong, of course. :)

• On my Sprint Note2 (which has a decent beefy CPU) I get ~+90% faster with jQuery than your HTML.js... though you are almost as fast as NoLIbary.
• sever/Node.js needs all the speed it can get with many users
• large tables/datasets
• animation/looping

Taking a quick glance at your code, not sure how to speed things up other than experimenting swapping .forEach with regualar for or while loops if you can.

[nbubna]

Yeah, HTML definitely requires IE9 and up. You can keep it from breaking in IE8 with a shim (i highly recommend http://github.com/kriskowal/es5-shim), but you can't get the dot-traversal syntax in IE8, because Object.defineProperty can only be shammed, not shimmed.

I don't see how your use-cases have anything to do with DOM selection/traversal, specifically. Remember what DOM selection is, it is the finding of an element or set of elements, not the interacting with them. If you are repeatedly doing that finding in a loop or high-performance situation, you are doing it wrong. Even speedy jQuery preaches against such things in all best-practices/optimization advice out there. Once you have found the elements you are working with, you reuse them.

And again, i looked at jQuery's trick, they test the selector to see if they can use getElementById or getElementsByClassName, then use those instead of querySelectorAll. That's not a hard trick to pull off, but i'm needing some convincing that DOM selection is an issue. I would be more inclined to work on speeding up a workhorse method like my each() implementation, than my find() implementation.

[nbubna]

Oh, more on the IE8 thing: i've got green light to do most of this work on HTML on company time, but we no longer accept Windows XP (and IE8 by extension) as first-class browsers. We try to keep our apps from being completely unusable on old IE, but do not try to keep them feature complete, and definitely aren't working to keep IE8 support in our front-edge library/tool development. It's officially far more important to spend our time/money supporting mobile form factors and features than the rapidly diminishing IE8 for all new development. If i get time myself, i may work on old IE support, but not on company time. :)

[tomByrer]

IMHO it is better to move forward & optimize for at least mobile browsers
(guessing 20% of traffic now?).

But as FYI, IE8 is installed by default with Win7. Many older people who
don't have a geek help them with their computer end up keep using it.
Occasionally webdevs are forced to be far-backwards compatible because of
undermanned IT shops. I know a dev I talked to 2 months ago forced to
program for IE6, for public schools around Denver.

Once you have found the elements you are working with, you reuse them.

Good point; I guess just ignore my prior comment for now & I'll keep an eye
out for specific use cases that might look up the DOM more than a dozen
time.

On Thu, Jul 25, 2013 at 11:12 PM, Nathan Bubna notifications@github.qkg1.topwrote:

Oh, more on the IE8 thing: i've got green light to do most of this work on
HTML on company time, but we no longer accept Windows XP (and IE8 by
extension) as first-class browsers. We try to keep our apps from being
completely unusable on old IE, but do not try to keep them feature
complete, and definitely aren't working to keep IE8 support in our
front-edge library/tool development. It's officially far more important to
spend our time/money supporting mobile form factors and features than the
rapidly diminishing IE8 for all new development. If i get time myself, i
may work on old IE support, but not on company time. :)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-21601873
.

[nbubna]

In the short run, excluding IE.old limits the developer audience slightly but retains my sanity. I'm competing with jQuery's future, not its past. Web devs forced to deal with IE 6/7/8 should thank the lords of the intertubes that jQuery 1.x exists and never deviate from it. I know i'd go running back there myself the second someone pressed for IE<9 support.

[tomByrer]

^ great way of putting it Nathan!

[adriancooney]

Sorry for the lack of response on this thread. Haven't had the time recently to give a worthy response.

@gratimax Having a function returned instead of a node would unfortunately have no effect on the performance because you'd still require the Object.defineProperty to expand a node's children unto itself. Infact, that was actually the original idea for the syntax. I eventually had to decide whether I wanted a node or function returned. I spent quite a while deciding between the two and finally decided on the node. The reasons I chose it because firstly, the function added (albeit small) an extra step between you and the node and secondly, I'd have to introduce a wealth of extra functions to enable the same flow as the dot notation. I understand where you're coming from though and appreciate the input.

@nbubna, @tomByrer Interesting discussion on the browser support. Personally, I don't think <IE9 is critical to a project but should definitely something to work to. Nathan's HTML fork is absolutely awesome. The each function is really intuitive and incredibly handy. Definitely surpasses Voyeur in functionality.

In relation to the status of the project; ES6 has an upcoming feature called Proxies which adds, from what I gathered, the ability to define wildcard getters on an object (think Object.defineProperty(obj, "*", {...})) which is exactly what Voyeur needs. In the meantime, I'll lobby for the performance improvement in the various mailing lists for Object.defineProperty and hopefully something good will come out of it. It's great to see the interest and discussion on Voyeur. A future could be in store for it.

[jkroso]

is it not possible to extend the prototypes with getters. that way you would only doing it once so defineProperty can be as slow as it likes.
e.g.

Object.defineProperty(Node.prototype, 'a', {
  get: function(){
    return filter(this.children, function(child){
      return child.tagName === 'A'
    })
  }
})

actually come to think of it you might not even need to extend any natives since you can create a kind of proxy similar to a jquery object but with getters/setters instead of methods.

[nbubna]

It certainly is possible, but that's a pretty radical change from a stepping lightly to aggressively populating the entire DOM with a whole slew of elements. It would also fail to account for any custom elements in the DOM, though admittedly it is becoming the convention for custom elements always include '-' in their tagName, which dulls the usefulness of the dot-traversal syntax.

I have considered doing this in HTML(.js) nonetheless, but i currently prefer the flexibility of the "step lightly" approach and have demonstrated (see the jsperf above) that the performance of the technique can be improved to the point that it is not a hindrance to any but the most strenuous (and unlikely) DOM traversal cases.

Creating a proxy will have to wait until Proxy becomes a widely available standard. Otherwise, you end up trying to replicate/rewrite the entire DOM interface in your wrapper library, as jQuery and friends have pretty much already done. Even then, i suspect the cost of proxying each node handled may prove higher even than these getters.