loading...

re: Tight Code 1: When immutability goes bad VIEW POST

FULL DISCUSSION
 

Of course naively using the JavaScript array will cause enormous memory bloat -- it is not optimized for immutability. It is not even immutable.

Languages supporting immutable by default data structures, such as Clojure and Haskell, use optimizations such as structural sharing to avoid reallocating identical contents.

For JavaScript, structural sharing is implemented by immerjs.

 

So:

a) You can find dozens of examples on this site that use immutability incorrectly - as I said, I don't disagree it can be useful, but don't just believe you need to keep local things immutable and that's what immer helps with.

b) Immer js is brilliant! It's not magic though. What immer's benefit is that it commits your mutable transactions at the end of a process, not in the middle alleviating a ton of thinking and potential slowness. It's still between 20 and 40 x slower than mutating an array in the example I gave. Now this makes is pretty useful in most UI circumstances, you can probably afford that kind of overhead in many circumstances.

 

I see. It is indeed a good thing to have one most post so people are more likely to stumble upon this information.

Thanks for the benchmark! I agree immutability is not free. Even Haskell uses internal states within high performing data structures.

Agreed, I mean my projects nearly 100% use some kind of immutability - my whole currently developed system is predicated on using transaction records and never mutating core data. I also love immer.js.

What I want to do in this series is just to point out - sometimes we should examine things in the tightest parts of our code if we are striving for 60fps. Oh yeah, and never do that stuff with [...blah, newThing] if there's a chance we will do it often! - That is just silly :)!!

code of conduct - report abuse