4 ms·

> Om never does any work it doesn't have to: data, views and control logic are not tied together. If data changes we never immediately trigger a re-render - we

> Om never does any work it doesn't have to: data, views and control logic are not tied together. If data changes we never immediately trigger a re-render - we simply schedule a render of the data via requestAnimationFrame. Ember.js has done this since day one with the Run Loop. Additionally it allows to coalesce operations yourself if you need control. Angular also would not update the DOM as many times as the backbone example as it uses dirty checking to get around this problem.

avolcano 13y ago
Yeah, I think it's rather misleading to compare om to the performance of the least optimized and most naive (on purpose, mind you) framework instead of a more robust one.
- programnature 13y ago
  There are benchmarks comparing vanilla React to other frameworks: http://facebook.github.io/react/blog/#todomvc-benchmarks http://facebook.github.io/react/blog/#todomvc-benchmarks At least according to this data, React and Backbone are the fastest. (Om is faster than vanilla React) One suspects that with hand-optimization the other frameworks could be a lot faster, but the point of this post is that it is fast without hand-optimizations.
  - peterhunt 13y ago
    Keep in mind that those benchmarks don't use the requestAnimationFrame() batching strategy (out-of-the-box it's not installed since it makes testing harder since you have to wait for the next frame) like swannodette mentions. I'd be interested to see these numbers after doing `npm install react-raf-batching` and doing `require('react-raf-batching').install()`.
  - esailija 13y ago
    In general "faster without optimization" is completely meaningless because it doesn't mean fast with optimization, which is what actually matters. Example: Average code written in node.js is typically just as slow as, say, PHP (in fact node.js was 3x slower than php in techempower benchmarks). However, it has potential to be much faster when optimized whereas PHP doesn't reward such optimization almost at all.
swannodette 13y ago
While it's nice that Ember.js provides a run loop that's not enough, just batching all your updates into one place just puts all of the work together, you'll still going to pay for the work and in the worse case you have to hand coalesce, yuck. In Om if there is no work ... there is no work, it's implicit in the system! No need for hand coalescing your state changes. Angular.js still suffers as shown by the optimization article I linked to in my post. These kinds of typical optimizations can and should be pushed out of the user's hands.
- ef4 13y ago
  You're misunderstanding. There's no hand coalescing in Ember, and there's no duplicate work. If you change your models a thousand times in a row, you still get one redraw, fully automatically. The same holds for dependent computed properties. If you change a dependencies many times in a row, the dependent property only reevaluates once.
  - swannodette_ 13y ago
    If that's really true for Ember.js that's great! I'm curious as to why it performs so badly? http://www.petehunt.net/react/tastejs/benchmark.html http://www.petehunt.net/react/tastejs/benchmark.html
    - EvilTrout 13y ago
      I looked at that benchmark and there's a few huge red flags right away: 1. It's not running Ember in production mode which is much faster. 2. It's running an older release candidate version of Ember. 3. It is purposely wrapping individual events in run loop executions rather than just letting ember figure out when you put things into run loops. I re-ran the benchmarks with the latest production mode Ember.js and removed the incorrect run loop usage got the following results: https://gist.github.com/eviltrout/8058560 https://gist.github.com/eviltrout/8058560 It's still slower than ReactJS but much less so than before. In fact it's now #3 in that benchmark suite behind ReactJS and Backbone (and much faster than ReactJS in the completing benchmark), although I wouldn't be surprised if the other frameworks were set up as incorrectly too.
cpprototypes 13y ago
How does the performance of this compare to AngularJS? Also a common performance issue in AngularJS is when there are too many watchers (such as a large table with many rows and columns) which causes the $digest to become really slow. Would Om/React avoid these kind of performance issues?

avolcano 13y ago

Yeah, I think it's rather misleading to compare om to the performance of the least optimized and most naive (on purpose, mind you) framework instead of a more robust one.

programnature 13y ago
There are benchmarks comparing vanilla React to other frameworks: http://facebook.github.io/react/blog/#todomvc-benchmarks http://facebook.github.io/react/blog/#todomvc-benchmarks At least according to this data, React and Backbone are the fastest. (Om is faster than vanilla React) One suspects that with hand-optimization the other frameworks could be a lot faster, but the point of this post is that it is fast without hand-optimizations.
- peterhunt 13y ago
  Keep in mind that those benchmarks don't use the requestAnimationFrame() batching strategy (out-of-the-box it's not installed since it makes testing harder since you have to wait for the next frame) like swannodette mentions. I'd be interested to see these numbers after doing `npm install react-raf-batching` and doing `require('react-raf-batching').install()`.
- esailija 13y ago
  In general "faster without optimization" is completely meaningless because it doesn't mean fast with optimization, which is what actually matters. Example: Average code written in node.js is typically just as slow as, say, PHP (in fact node.js was 3x slower than php in techempower benchmarks). However, it has potential to be much faster when optimized whereas PHP doesn't reward such optimization almost at all.

swannodette 13y ago

While it's nice that Ember.js provides a run loop that's not enough, just batching all your updates into one place just puts all of the work together, you'll still going to pay for the work and in the worse case you have to hand coalesce, yuck. In Om if there is no work ... there is no work, it's implicit in the system! No need for hand coalescing your state changes. Angular.js still suffers as shown by the optimization article I linked to in my post. These kinds of typical optimizations can and should be pushed out of the user's hands.

ef4 13y ago
You're misunderstanding. There's no hand coalescing in Ember, and there's no duplicate work. If you change your models a thousand times in a row, you still get one redraw, fully automatically. The same holds for dependent computed properties. If you change a dependencies many times in a row, the dependent property only reevaluates once.
- swannodette_ 13y ago
  If that's really true for Ember.js that's great! I'm curious as to why it performs so badly? http://www.petehunt.net/react/tastejs/benchmark.html http://www.petehunt.net/react/tastejs/benchmark.html
  - EvilTrout 13y ago
    I looked at that benchmark and there's a few huge red flags right away: 1. It's not running Ember in production mode which is much faster. 2. It's running an older release candidate version of Ember. 3. It is purposely wrapping individual events in run loop executions rather than just letting ember figure out when you put things into run loops. I re-ran the benchmarks with the latest production mode Ember.js and removed the incorrect run loop usage got the following results: https://gist.github.com/eviltrout/8058560 https://gist.github.com/eviltrout/8058560 It's still slower than ReactJS but much less so than before. In fact it's now #3 in that benchmark suite behind ReactJS and Backbone (and much faster than ReactJS in the completing benchmark), although I wouldn't be surprised if the other frameworks were set up as incorrectly too.

cpprototypes 13y ago

How does the performance of this compare to AngularJS? Also a common performance issue in AngularJS is when there are too many watchers (such as a large table with many rows and columns) which causes the $digest to become really slow. Would Om/React avoid these kind of performance issues?