Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance on latest Chrome (Version 38.0.2125.111 m) #2

Open
BartAdv opened this issue Nov 7, 2014 · 4 comments
Open

Performance on latest Chrome (Version 38.0.2125.111 m) #2

BartAdv opened this issue Nov 7, 2014 · 4 comments

Comments

@BartAdv
Copy link

BartAdv commented Nov 7, 2014

It's much worse than that of React'. Is it something with latest version of Chrome? IE11 shows much better performance. I know it's most likely virtual-dom issue, but I don't know the details so I'm just raising it here out of pure curiosity.

@staltz
Copy link
Owner

staltz commented Nov 8, 2014

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.

@staltz
Copy link
Owner

staltz commented Nov 8, 2014

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.

@staltz
Copy link
Owner

staltz commented Nov 8, 2014

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.

@Raynos
Copy link

Raynos commented Nov 9, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants