0

I read about React being very fast. Recently, I wrote an app to test react against angular. Unfortunately I found react performing slower than angular. http://shojib.github.io/ngJS/#/speedtest/react/1

Here is the source code for react. I'm very new to react. I am sure I'm doing something wrong with my react code here. I find it unusually slow. https://jsbin.com/viviva/edit?js,output

See if any react experts can find the bottlenecks.

Update 1:

  1. Removed the usage of context.
  2. Better usage of setState.
  3. Better usage of shouldComponentUpdate.

I still can't make it faster than angular or even close to it. https://jsbin.com/viviva/96/edit?js,output

Update 2:

I made a big mistake by creating 2d arrays in the cell component. So I moved them to a mixin. Now I believe that react is faster than angular in DOM manipulations. https://jsbin.com/nacebog/edit?html,js,output

Update 3:

My mistake again. I did it wrong which made it faster. After analysis, it was rendering incorrectly. If anyone can help me understand, if this could be any faster. I know react is not good at dealing large arrays. In this scenario, it's dealing with four 3d arrays. https://jsbin.com/viviva/100/edit?html,css,js

user730009
  • 313
  • 1
  • 5
  • 18

3 Answers3

2

React's performance is exaggerated. It's fast enough for most real use cases. Rendering large lists is its main weakness.

Also this always returns true (unless the update is triggered by setState). You need to shallow compare the props.

  shouldComponentUpdate: function(nextProps, nextState) {
    return this.props !== nextProps;
  }

And you should be using props in the places you're using context.

Brigand
  • 84,529
  • 20
  • 165
  • 173
  • I don't know if context can degrade performance. But I find context to be very useful. If I want to pass information from parent to grandchild without passing it to a child first, I can achieve that using context. If I have a more complex hierarchy, I wouldn't want to pass information to all child nodes even-though I meant that information only for the grandchild nodes. – user730009 Jan 25 '16 at 18:09
  • @user730009 context is not meant to be used to pass data to a whole tree but rather to pass data that does not change often to the whole tree. If your context data changes, you should be very careful of updating that whole tree because re-render is not triggered. If you want to pass data to a deep child without boilerplate you should consider Flux or Redux – Sebastien Lorber Jan 25 '16 at 22:20
  • Also React is not the best to render large lists but there are potential optimizations that have not been very experimented yet. I've done some here: http://stackoverflow.com/questions/30976722/react-performance-rendering-big-list-with-purerendermixin – Sebastien Lorber Jan 25 '16 at 22:21
1

You're using context incorrectly, the documentation states:

In particular, think twice before using it to "save typing" and using it instead of passing explicit props.

It's mostly beneficial for passing context objects like currently logged in user or perhaps a redux store. Your app is using context when it should be using props.

You'll need to ensure that shouldComponentUpdate is a meaningful predicate. See https://facebook.github.io/react/docs/advanced-performance.html

If you correct those two things it'll be a better measure of React's performance compared to Angular. At the moment you've got a well tuned Ferrari running against a model T Ford (held together with chewing gum).

Todd Moore
  • 420
  • 2
  • 7
1

This is a very contrived example in my opinion.

  • As stated above, you are using context incorrectly.
  • There is no need for a mixin: the number of columns and rows can and should be passed down as props. create2DArray, getRandomNumber should be declared at the top of your script as simple global functions.

  • You are setting the state incorrectly. You should never change the state like this this.state.some = 'whatever', you have to use setState

    this.setState({ some: 'whatever' });

Raspo
  • 1,048
  • 1
  • 7
  • 20
  • There is nothing wrong with mixins per se. I'm just saying that I don't think they are necessary in this particular example. Also, the API for mixins MAY go away in the future, here is an interesting read: https://medium.com/@dan_abramov/mixins-are-dead-long-live-higher-order-components-94a0d2f9e750#.c584pmbtp – Raspo Jan 26 '16 at 21:23