2 ms·

To respond in advance: Yes, this is an entirely artificial setup. The point is to start to get a feel for the overhead that different binding strategies can inc

To respond in advance: Yes, this is an entirely artificial setup. The point is to start to get a feel for the overhead that different binding strategies can incur -- a question that folks often ask about. If you're never rendering complicated UI, or never have more than a couple models, this will never make a difference. But if you have a large list of models, or need to run in IE8, or need to run on mobile, it very well may. Edit: For folks wondering about the cause behind the difference -- Yehuda's looked into it more, and knows more about it than I do -- but there are a number of factors that could be at play: * bulk innerHTML updates vs. granular DOM twiddling (especially in different browsers). * Handlebars vs. Underscore templates -- although Handlebars templates are quite fast. * Fine-grained bindings needing to be kept in sync inside of Ember for Metamorph.js purposes. * Other miscellaneous overhead. Some quality time with the Chrome CPU profiler should be able to tell you more. FWIW, Yehuda seems to link it's the latter: overhead that should be possible to eliminate in time. Edit 2: Looks like @ericf's forked and added a new YUI version: http://jsfiddle.net/ericf/NrpcQ/ http://jsfiddle.net/ericf/NrpcQ/

mrchess 15y ago
In reply to the edit -- would be cool if someone could extend this to ExtJS as well just for the heck of it.
- Flow 15y ago
  And Cappuccino :)
  - erichocean 15y ago
    And Blossom.
wycats 15y ago
I can address some of these, as I've been staring at the profile quite a bit: "bulk innerHTML updates vs. granular DOM twiddling (especially in different browsers)." A part of the cost is definitely in making these small changes, but not a huge part. For what it's worth, we're in the process of implementing a feature that would allow you to specify the re-rendering granularity in the template itself, but we don't want it to be heavily used by end-users. "Handlebars vs. Underscore templates -- although Handlebars templates are quite fast." I don't see the cost of rendering handlebars templates at all in the top of the profile, which is not surprising, as the templates we're rendering are very small, and Handlebars templates are very fast. "Fine-grained bindings needing to be kept in sync inside of Ember for Metamorph.js purposes." The cost of bindings are not ongoing, but rather when a `set` happens. Internally, this code is somewhat equivalent to the Backbone event system (we even trigger `change:foo` events) with some more chrome on top to manage things like computed properties. Most of the cost here is not in the internals of the binding system, but rather in the effects of the binding system, like re-rendering the `{{content}}` and updating the style. In short, the internals of Ember know about as much on an ongoing basis as Backbone's internals know: namely, that there is an observer on `change:content` that needs to be triggered when the underlying property changes. Again, we do more work once that event is triggered than Backbone does, but the vast majority of the cost is on the receiving end of the events, not in the event system itself. "Other miscellaneous overhead." From my analysis of the profile, this looks to be the primary cost. The view layer itself could stand to be more optimized. For example, we use a state machine internally to control what events are legal in different states (preRender, inBuffer, hasElement, inDOM). It was our first state machine implementation inside of Ember, and we didn't do some obvious optimizations (like cache legal transitions). The ember-states code, which ships with ember and is used in ember-data, is far more optimized, and moving to use it should eliminate some of the cost I'm seeing. At the very least, it provides us with a central state machine implementation that we can continue to optimize over time, resulting in performance improvements all around. There are other areas where micro-optimizations will almost certainly help (such as in the event system itself and how it's used).
- krisselden 15y ago
  A bit more of an apples to apples comparison http://jsfiddle.net/krisselden/bYPPT http://jsfiddle.net/krisselden/bYPPT and just to illustrate, Ember doesn't force you to micro bind and one would never suggest it for animations.

mrchess 15y ago

In reply to the edit -- would be cool if someone could extend this to ExtJS as well just for the heck of it.

Flow 15y ago
And Cappuccino :)
- erichocean 15y ago
  And Blossom.

wycats 15y ago

I can address some of these, as I've been staring at the profile quite a bit: "bulk innerHTML updates vs. granular DOM twiddling (especially in different browsers)." A part of the cost is definitely in making these small changes, but not a huge part. For what it's worth, we're in the process of implementing a feature that would allow you to specify the re-rendering granularity in the template itself, but we don't want it to be heavily used by end-users. "Handlebars vs. Underscore templates -- although Handlebars templates are quite fast." I don't see the cost of rendering handlebars templates at all in the top of the profile, which is not surprising, as the templates we're rendering are very small, and Handlebars templates are very fast. "Fine-grained bindings needing to be kept in sync inside of Ember for Metamorph.js purposes." The cost of bindings are not ongoing, but rather when a `set` happens. Internally, this code is somewhat equivalent to the Backbone event system (we even trigger `change:foo` events) with some more chrome on top to manage things like computed properties. Most of the cost here is not in the internals of the binding system, but rather in the effects of the binding system, like re-rendering the `{{content}}` and updating the style. In short, the internals of Ember know about as much on an ongoing basis as Backbone's internals know: namely, that there is an observer on `change:content` that needs to be triggered when the underlying property changes. Again, we do more work once that event is triggered than Backbone does, but the vast majority of the cost is on the receiving end of the events, not in the event system itself. "Other miscellaneous overhead." From my analysis of the profile, this looks to be the primary cost. The view layer itself could stand to be more optimized. For example, we use a state machine internally to control what events are legal in different states (preRender, inBuffer, hasElement, inDOM). It was our first state machine implementation inside of Ember, and we didn't do some obvious optimizations (like cache legal transitions). The ember-states code, which ships with ember and is used in ember-data, is far more optimized, and moving to use it should eliminate some of the cost I'm seeing. At the very least, it provides us with a central state machine implementation that we can continue to optimize over time, resulting in performance improvements all around. There are other areas where micro-optimizations will almost certainly help (such as in the event system itself and how it's used).

krisselden 15y ago
A bit more of an apples to apples comparison http://jsfiddle.net/krisselden/bYPPT http://jsfiddle.net/krisselden/bYPPT and just to illustrate, Ember doesn't force you to micro bind and one would never suggest it for animations.