[drfloob]

> it seems like it is invoking React's event loop more than I would expect ... Perhaps this difference is because of requestAnimationFrame?

I think so, yes. The performance difference is already negligible with Om, so I didn't see a real need to optimize it any further. Pete Hunt's react-raf-batching (mentioned already) could probably be dropped in to get that last bit of optimization, but I haven't tried.

As for what I mean by "application data policy", I think that if you work with your application's data in such a way that it batches modifications, renders entirely from the top down, and uses fast `shouldComponentUpdate` implementations, you'd achieve most of the improvement you see in the Om vs React+Backbone TodoMVC comparison. Lots of things could achieve that. Immutability isn't a hard requirement to get those features done. And if my React+_tree example is any indication, requestAnimationFrame isn't buying you that much performance either.

I haven't really analyzed what Om's Benchmark 2 was doing under the hood, so thank you for that. I assumed it was doing something, but with the ~4ms benchmark, I just assumed that particular something was wizardry.

[haberman]

> I think so, yes. The performance difference is already negligible with Om, so I didn't see a real need to optimize it any further.

Sorry, I was unclear: my comments were about the (slow) first benchmark you posted that is using React but not using your library. I think it would be orders of magnitude faster with requestAnimationFrame.

[drfloob]

EDIT: not true. see below.

----------------------------

Good call! Benchmark 1 is about 33x faster in my browser (with the setTimeout fallback being used, I think).~

http://drfloob.github.io/todomvc/labs/architecture-examples/...

This is the same React TodoMVC example with a different `react-with-addons.js`, built using React v0.9.0 and https://github.com/petehunt/react-raf-batching.

[swannodette]

The timings you are presenting in the UI are not accurate. But you are correct that this approach results in timings that are almost identical to Om. Use the Chrome Dev Tools profiler flamegraph if you want to confirm what I'm saying.

[drfloob]

Ah, right. Benchmark 1 is actually ~350ms on my machine. Thanks for the lesson in profiling asynchronous code. I revisited the React+_tree benchmark claims, too, and I think they are still spot on. If you're interested at all, I'd appreciate you taking the time to check my work there.

[swannodette]

I took a look but it's hard to judge since you are using React 0.8.0 and Om is now on React 0.9.0.