Question

The Redux framework favors immutable state/pure function paradigm, which promotes creation of new state from the previous state in terms of the current action. The applicability of this paradigm is indubitable.

A major concern of mine is that, as the Redux reducers eagerly return fresh new states from previous states for each and every action invoked, massive memory drain (not to be confused with memory leaks) would become a common occurrence in many real-world applications. When considering that Javascript applications normally run in a browser in an average user's devices which could also be running several other device specific applications and several more browser tabs and windows, the necessity to conserve memory becomes ever more evident.

Has anyone actually compared the memory consumption of a Redux application to the traditional Flux architecture? If so, could they share their findings?

Était-ce utile?

La solution

This is a valid concern. While I have not measured the memory usage of Redux applications, I think that before committing to use Redux (or any other framework for that matter) you should create stress tests that emulate the data amounts, change frequency, and computation intensity of the application you are going to build. Use these stress tests before making technological decisions about whether adopting immutability works in your particular case.

Note that sometimes people get confused about Redux and assume that on every action, the state tree has to be cloned deeply. This is absolutely not the case. Only the parts that changed need to change their references. For example, if an action causes a change to one item in an array, indeed, that item and the array will need to be copied, however, all other elements in the array will keep their identities. Because most of the times actions are very targeted and affect a few state keys, and because Redux encourages normalizing data so that the data structures are not deeply nested, this is much less of a problem for typical webapps than one might imagine.

You will also want to explore using libraries like Immutable.js that implement immutable lists and maps efficiently by using structural sharing internally. This way, changing a few items in a list doesn’t involve so much copying because internally most of the memory is being shared between different versions of the data structure.

But in the end, the only way to tell is to write the stress tests that closely emulate the intended usage of your app, and measure the efficiency for yourself.

Licencié sous: CC-BY-SA avec attribution
scroll top