Clarify meaning of "O(1)" vs "O(n)" reducers?

[markerikson]

Hi. I'm a Redux maintainer. I'm rather confused by this comment:

Fully compatible with Redux but works with O(1) speed when Redux itself works with O(N) speed (N is number of reducers).

Can you clarify what you're referring to here, and how fast-redux is different?

[dogada]

Hi Mark, thanks for your question. I added a note about performance to README. Also added several unit tests that demonstrate fast-redux usage.

[dogada]

Added examples to the repo. examples/async is deployed at https://dogada.github.io/fast-redux/

[markerikson]

Serious question: have you actually seen real performance issues with the standard Redux approach, such as use of combineReducers? Have you read http://redux.js.org/docs/faq/Performance.html#performance-all-reducers ?

Per the example on the front of the repo, yes, dispatching a separate Redux action for every keystroke in an input may not be the most efficient approach. But, that's primarily a question of how your connected UI components are set up, and not a factor of how long it takes to run the reducer logic.

[dogada]

Serious answer: even on those FAQ page you recommended above, it's mentioned performance problems in large application and suggested redux-ignore to workaround it.

Dan Abramov (@gaearon) seems agree with importance of this issue too:
https://twitter.com/dan_abramov/status/656049225566920704

I made a simple demo that shows delay of updating text field depending on reducers count: https://codepen.io/dogada/pen/QMdbJy?editors=0010

With 1000 reducers I have 5-10ms delay on moderate hardware only for useless reducers tree traversing that fast-redux completely avoids (with fast-redux I always have stable near 1ms delay). Add to this time for updating DOM tree and say goodbye to responsive UI, especially on slow mobile devices.

Other side of problem, current Redux implementation isn't scalable. The more reducers you have, the more CPU cycles and so battery you waste. With this approach Redux will not be green certified for sure ;)

[markerikson]

FWIW, your example is actually measuring both how long it takes the reducers to run and how long it takes React to update the UI. These are not the same thing.

I tried copying your example into a CodeSandbox project at https://codesandbox.io/s/wpo1vY2M8 , and changed it so that it's using the DOM APIs to update the stats. See what happens if you type quickly while changing between:

• Having the store subscribed to render, using createStore(rootReducer)
• Having the store subscribed to render, using createStore(noopReducer)
• Don't have the store subscribed, using createStore(rootReducer)
• Don't have the store subscribed, using createStore(noopReducer)

Check both the values displayed in the UI when the store is subscribed, and the console log output in all cases.

What I'm seeing, in FF54 on a reasonably powerful laptop, is that dispatching with noopReducer takes between 0-1ms (rounded), and dispatching with rootReducer takes 1-2ms (rounded).

My point here is that unless you have very complex reducers, your reducer logic is highly unlikely to be the bottleneck in an application. Instead, it's the cost of calling store subscribers (such as Redux-connected components) and updating the UI that will dominate perf. That's not to say that your lib is bad or useless, just that it's not going to have much of a meaningful perf impact in a real-world app. It's also worth noting that putting "reducer functions inside actions" is not a recommended approach, and may cause issues with time-travel debugging.

You may want to read through my blog post Practical Redux, Part 6: Connected Lists, Forms, and Performance and the slideshow High Performance Redux for more info, as well as the other articles in the Redux Performance section of my links list.

[popo63301]

Is this library still relevent?

[dogada]

@popo63301, yup I use it in my React projects last months and it works very well. Just published 0.7.1 version where I improved utils to work with properties of state objects.

I have less boilerplate code than with classical Redux implementation, perfect O(1) speed of updating store and it's easy to extend Redux store progressively in code-splitting scenarios.

It's also worth to mention that fast-redux it's fully compatibility with redux dev tools, you can use fast-redux action and state updates using them. Demo: https://dogada.github.io/fast-redux/