Performance on latest Chrome (Version 38.0.2125.111 m) about mvi-example HOT 4 OPEN

I suppose you're talking about modifying items in the presence of many items (after "adding many items")? Related to this twitter discussion:
https://twitter.com/sudodoki/status/531188562746949632
@sudodoki

I did some digging into both React and MVI sides, and apparently it's true, React is performing much better and it seems to be all due to PureRenderMixin.

See this comment.

In both React and MVI implementations of this example, the whole set of elements is rerendered, but in React, PureRenderMixin has a smart check to avoid a diff calculation for the Item component. That doesn't exist in MVI/virtual-dom.

This is a good find, and it's not virtual-dom's fault because its responsibility is just diff and patch. PureRenderMixin works a bit higher in the architecture, close to "properties and state" of a React component. I'll think what could be done, but I'm open to suggestions.

from mvi-example.

I also filed an issue for virtual-dom: #113

I have one back-of-the-envelope idea: to attach the parent data (or React "property") to the VTree, and inside virtual-dom's diff algorithm, it could use that data instead of the whole VTree structure, as a quick diff check prior to the real diff. Maybe we could even use a hash of the data instead of the data itself.

from mvi-example.

Oh well, I'm just starting to figure out that virtual-dom (and mercury) has plenty of tricks for optimizing performance. This issue is very relevant for our demo.

In fact, it seems that the whole point of the React demo is to demonstrate performance gains with shouldComponentUpdate, because the title of the demo is "Demo 6: Top-Down Data Flow & shouldComponentUpdate".

It seems I chose the wrong demo for comparing MVI and React, because it was supposed to be a fight between React's PureRenderMixin and virtual-dom's optimizations, but there were no virtual-dom optimizations employed.

I'll get my head around virtual-dom optimization specifics and update this demo later.

from mvi-example.

Use thunks.

There are a few more performance issues with large lists based on ( Raynos/mercury#97 ).

The main performance issue is hooks and the way <input> is implemented in virtual-hyperscript.

from mvi-example.