[acemarke]

> Dispatch is another big culprit.

Could you clarify what you mean by that?

Per both of your comments: generally speaking, your `mapState` functions _should_ run as quickly as possible. Ideally, a `mapState` function should just grab a couple values from the Redux state object and return those.

If a component needs the store data to be transformed in some way, we recommend using memoized selector functions [0] to cut down on unnecessary work.

So, in a well-written app, your `mapState` functions shouldn't be bottlenecks.

As I said, if you've got some examples of specific perf issues, I'd be happy to offer advice.

[0] https://blog.isquaredsoftware.com/2017/12/idiomatic-redux-us...

[kalkut]

> Could you clarify what you mean by that?

A call to dispatch is significantly more expensive than the update of a JS object

> Ideally, a `mapState` function should just grab a couple values from the Redux state object and return those.

Ideally it should, but in practice it is really much more expensive than getting a value in a JS object

> If a component needs the store data to be transformed in some way, we recommend using memoized selector functions [0] to cut down on unnecessary work.

I used Reselect before removing Redux. Beyond the fact that it adds a lot of boilerplate it does not help if you do need a lot of data updates.

> So, in a well-written app, your `mapState` functions shouldn't be bottlenecks.

It shouldn't but a few dozen of updates per second through Redux on a mobile take a toll on its performance serious enough to not be able to keep 60fps in a WebGL context.

I decided to remove Redux after noticing the performance overhead per function call in the Chrome performance profiler, so I know that in practice "dispatch" and "mapState" are not comparable to just editing or grabbing "a couple values from the Redux state"

My ex-coworker had the same issues because he needed to display a lot of items handled collaboratively with smartphones. In both of our cases we have a high rate of data updates, even if we optimize like crazy we are never going to fall under 4-5 update/second per connected user.

So yeah Redux can run well for webapps with a slow/regular pace of update but for more performance sensitive apps you do pay a Redux performance tax.

Again I still use Redux on some projects and I like it but the limits are there. So now I don't hesitate to do without it first and to use it when I need its abstraction.

[acemarke]

Hmm. Could you maybe file an issue on the React-Redux repo and provide some repro examples for your use case? I'd be interested in seeing the perf traces myself. This would also be valuable as we work on refactoring React-Redux to work with the new React context API. I have a hunch that my proposed architecture will improve perf, but having more benchmarks would be helpful.

[kalkut]

You really are helpful and you try to fix this so I really want to say yes but I am currently grinding for my own startup so I know that a lot of time will pass before I actually do it so I don't promise anything.

A good way to test it would be to make a simple websocket server that simulate n users each sending n' fake xyz position and rotation data per second. This data updates a Redux store in a React app made with Aframe (HTML wrapper around ThreeJS). You make n cubes move and rotate along the data in the store. Compare the fps you get against the fps you get with a vanilla solution. Also check what happens on the performance tab of chrome

I am able to recognize that my use case is very specific. I used React/Redux/Reselect and Aframe/ThreeJS with sockets a year ago. Now I kept React but the rest of the stack have changed for nearly a year

[acemarke]

Gotcha. I've made a note of this in https://github.com/reactjs/react-redux/pull/898 for future reference.

If you ever do have some free time to throw together an example app that demonstrates this behavior, please feel free to link it in that issue, or ping me directly (Twitter and Reactiflux are usually best).

[kalkut]

I ended up hacking a benchmark. I couldn't beat that itch !

I mentioned it in the pull request, here it is : https://github.com/Kalkut/redux-data-frequency-benchmark

[mosdl]

The problem is that they run too often, not that they are slow. mapStateToProps is called too often, and that leads to a bunch of needless shallow compares and often renders. Its a weakness of the magic design, and if I need to optimize the magic might as well just implement the whole thing.