Hacker News new | ask | show | jobs
by kalkut 2900 days ago
> 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.

1 comments

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

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

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