[drfloob]

Well, we can check a few of those guesses pretty easily. Here is the stock React TodoMVC demo augmented with Swannodette's benchmarks:

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

Benchmark to your heart's content! On my system, Om is about 4x faster on benchmark 1, and 1000x faster on benchmark 2. I don't think requestAnimationFrame has a lot to do with it, and immutability only slightly more; I think the real performance gain is in having an application data policy tailored to make the most of React's behavior.

To plug my own work a bit, I built a TodoMVC example with React and my own immutable data structure library in pure JS. It performs a lot like Om on both benchmarks, and actually seems a bit snappier in places, like toggling and clearing all completed todos:

http://drfloob.github.io/todomvc/labs/dependency-examples/re...

[haberman]

Thanks for posting this; I wished when writing the article that I had plain React benchmarks to run.

However when I profiled your benchmark it seems like it is invoking React's event loop more than I would expect (and more than the React/Om benchmark does) -- do you have any idea why this would be? It seems like for this to be apples to apples, it shouldn't be invoking React's update logic (ie. re-rendering everything) until the end of the benchmark. Perhaps this difference is because of requestAnimationFrame?

I don't understand this comment:

> I don't think requestAnimationFrame has a lot to do with it, and immutability only slightly more; I think the real performance gain is in having an application data policy tailored to make the most of React's behavior.

As I mentioned in my article, "Benchmark 2" is a no-op on the DOM. So literally all React should be doing is calling render() before the benchmark (which returns basically nothing), letting the entire benchmark run, then calling render() again (in which it again returns basically nothing).

In other words, I don't see what the "application data policy" has to do with making React efficient in this case; all we're asking React to do here is calculate a no-op diff and then do nothing.

[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.

[dangoor]

Interesting stuff. Have you compared _tree with Mori?

[drfloob]

Thanks. I knew of Mori, but hadn't looked at it yet. Now that I've glanced, you could definitely implement something like _tree with Mori, but it'd be missing a few key things.

What jumps out most is that I'd really miss batch mode, which lets you escape from immutability and get a big performance boost for complex atomic operations. I think Mori must use something like this internally, but the docs don't indicate it being exposed.

It may be subtle, but I also really prefer _tree's syntax, where objects are fitted with their own methods (Mori does something like `mori.get(m0, 'foo')` instead of the more succinct `m0.get('foo')`). This is also the backbone of _tree's data modeling layer, which lets you work in terms of your domain, rather than a tree.

Performance comparisons are on my list of things to do.

[dangoor]

Mori's data structures are the ones from ClojureScript, so they're designed in a functional, rather than OO, style. I agree it's more foreign in a JS context. For some operations, there are advantages to being able to write functions that just work with generic data rather than objects. I could imagine having a layer on top of Mori that provides a more familiar face while still giving access to the "just data" stuff underneath for performing functional operations.

Pete Hunt did just that:

https://github.com/petehunt/morimodel/

Mori is sophisticated under the hood. It doesn't do massive amounts of copying or anything like that, so I don't think you need a "batch mode" to make it perform. Perhaps I'm missing something though.

Edit: I took a quick look at _tree's code. It's quite different from how I understand Mori to work. Mori exposes Clojure's data structures which implement their own immutable maps, lists and vectors in a way that is very efficient for copying (both in time and space).

[drfloob]

Thanks dangoor. It's a good day when someone shows me two recent projects that are very similar to my own. I started _tree a few months back because I couldn't find a project like it. Turns out I'm in good company.

_tree leans heavily on functional programming techniques, so it's not so different at all. The furthest it gets from functional is the modeling layer implementation, which is prototypal, and still just a thin layer over the core.

I haven't studied any clojurescript, but conceptually, compound operations on immutable structures, such as re-parenting a subtree or sorting a vector/list/set, would be implemented inefficiently without mutable intermediate objects. For example, imagine writing quicksort where exchanges cost O(n) instead of O(1). Performance would totally tank. It'd be silly.

That's why I expect clojurescript has mutable intermediates. I'd love for someone to prove this guess wrong, it would blow my mind. Anyway, that's what _tree's batch mode is, in essence: exposed access to the mutable, pre-finalized versions of _tree primitives.

[piranha]

It's a bit more sophisticated than that.

https://news.ycombinator.com/item?id=7292588

[drfloob]

Right, it sounds like they use tries with 5 bit keys. It's a very neat data structure, for sure, but _tree is just at a lower level. It doesn't impose structure. Tries can be implemented in _tree.