24

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?

3
  • 4
    I'm voting to close this question as off-topic because it is asking for arbitrary memory profiling information.
    – user40980
    Feb 8 '16 at 2:31
  • Have you profiled it?
    – user22815
    Feb 9 '16 at 5:25
  • Why should I profile it? To confirm the obvious? Is it not common sense that spawning a similar object over and over again incurs a serious overhead in terms of memory usage? @Dan's answer provides a way to minimize that overhead and that is the best answer so far. Feb 9 '16 at 15:55
31

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.

2
  • 10
    Don't be so quick to jump to Immutable.js. It's becoming a serious memory hog in our case. Immutable.js takes your (presumably) neat plain objects and instantiates them into memory-hungry monsters. Take a look at this example: jsfiddle.net/sn70x2p6 After load, the tab takes 61,000KB memory. After making a million plain objects, it's 211,000KB. Crazy. Now click "make immutable" and see what happens. It jumps to over 1GB memory usage. You experience may differ, but not much. Sep 22 '16 at 15:48
  • @OlavKokovin I'm sure you conclusions aren't correct. Please see my comment. In runtimes with garbage-collector (line JVM, V8), mainly objects that are long lived ans survice GC cycle cause performance and memory footprint impact.
    – sgnsajgon
    May 11 '20 at 20:46

Not the answer you're looking for? Browse other questions tagged or ask your own question.