4 ms·

I thought that the reason for immutability wasn't so much for performance as much as for getting predictable state to enable time-travel, etc.

feedjoelpie 11y ago
As I understand it, immutability makes management of state on complex objects easier to deal with. Whereas ImmutableJS the library makes immutability performant in JS. Someone please correct me if I'm wrong because I cannot seem to locate my source anymore, but I believe what ImmutabilityJS does is not actually deep-copy complex objects, but reuse references to nested objects that have not changed. Such that you get a new object, but not everything in the object is new, which is what keeps things fast.
- Cshelton 11y ago
  When you use Immutable JS, you are taking a slight performance hit. You are creating a new object every time you change anything and returning it. But the benefit of not having to worry about unexpected changed or sometimes referencing something you didn't mean too is great. The added performance can come from the equality checks. Like, do not do anything if newState === oldState. This has added benefit with something like React where you can use shouldCOmponentUpdate, which we returned false, will not call the render function. It can increase performance drastically on complicated things.
  - woah 11y ago
    I think you know this, but just so that nobody gets the wrong idea- the new object created only uses as much memory as the difference between the new object and the old one. Immutablejs keeps track of the diffs and presents an interface to something that acts like a whole new object but consists of the old object + diffs. So if you are replacing some in-place array mutation with Immutablejs code, this will use slightly more memory. However, if you are replacing native .map, .reduce, or .filter code with the equivalent Immutablejs, you will actually use less memory, because the built in methods clone the entire object.
masklinn 11y ago
It's performance wrt state invalidation for work skipping. The library can check the state tree, and if the tree (or subtree) has not changed skip rendering entirely. With mutable state limited assumptions can be made so by default you have to render to vdom and diff that. With immutable state you can do an identity check on the current state node (pretty much free), and only perform the render if it fails. On specific components you may want to go further and do a deeper equality check if the identity check fails (if rendering is expensive) but immutable collections generally give a lot of bang for your buck when it comes to skipping state -> vdom.
- guscost 11y ago
  I've actually used a plain state object with UUID version tags saved at each node that needs to be optimized. Whenever the store updates that node, it also updates the version tag with a new UUID. Then shouldComponentUpdate just checks whether the version tag is different before rendering. For my purposes this optimizes at least as well as ImmutableJS, and there is no overhead from loading and using a dedicated library. However it does require extra boilerplate and manual updates to version tags each time something changes, and it can cause confusion if you forget to update a version tag or accidentally update the wrong one. Anyway, it is one alternative, but if you don't have a compelling reason not to use ImmutableJS for optimization I'd probably go with that. Of course it is perfect for undo/redo functionality too if that is a requirement.
  - rymohr 11y ago
    Your approach sounds interesting. Ever write about it? The undo / redo gains of ImmutableJS quickly vanish when you're working with remote data and the leaked getters aren't fun. A little UUID juggling is worth it if it allows my components/reducers to work with plain old javascript objects and still get fast shouldComponentUpdates.
    - guscost 11y ago
      It's one of the ideas for shouldComponentUpdate that I wrote about here, but it's not described in a lot of detail: http://guscost.com/2015/05/27/react-js-and-flux-ideas-for-practical-applications/ http://guscost.com/2015/05/27/react-js-and-flux-ideas-for-pr... One of these days I'll put up another piece on Flux/React, and an example application to demonstrate an approach that doesn't have a lot of dependencies (not even ES6, for example). Also I have not run into any pitfalls using ImmutableJS yet apart from the extra overhead, so thanks for the heads up.

feedjoelpie 11y ago

As I understand it, immutability makes management of state on complex objects easier to deal with. Whereas ImmutableJS the library makes immutability performant in JS. Someone please correct me if I'm wrong because I cannot seem to locate my source anymore, but I believe what ImmutabilityJS does is not actually deep-copy complex objects, but reuse references to nested objects that have not changed. Such that you get a new object, but not everything in the object is new, which is what keeps things fast.

Cshelton 11y ago
When you use Immutable JS, you are taking a slight performance hit. You are creating a new object every time you change anything and returning it. But the benefit of not having to worry about unexpected changed or sometimes referencing something you didn't mean too is great. The added performance can come from the equality checks. Like, do not do anything if newState === oldState. This has added benefit with something like React where you can use shouldCOmponentUpdate, which we returned false, will not call the render function. It can increase performance drastically on complicated things.
- woah 11y ago
  I think you know this, but just so that nobody gets the wrong idea- the new object created only uses as much memory as the difference between the new object and the old one. Immutablejs keeps track of the diffs and presents an interface to something that acts like a whole new object but consists of the old object + diffs. So if you are replacing some in-place array mutation with Immutablejs code, this will use slightly more memory. However, if you are replacing native .map, .reduce, or .filter code with the equivalent Immutablejs, you will actually use less memory, because the built in methods clone the entire object.

masklinn 11y ago

It's performance wrt state invalidation for work skipping. The library can check the state tree, and if the tree (or subtree) has not changed skip rendering entirely. With mutable state limited assumptions can be made so by default you have to render to vdom and diff that. With immutable state you can do an identity check on the current state node (pretty much free), and only perform the render if it fails. On specific components you may want to go further and do a deeper equality check if the identity check fails (if rendering is expensive) but immutable collections generally give a lot of bang for your buck when it comes to skipping state -> vdom.

guscost 11y ago
I've actually used a plain state object with UUID version tags saved at each node that needs to be optimized. Whenever the store updates that node, it also updates the version tag with a new UUID. Then shouldComponentUpdate just checks whether the version tag is different before rendering. For my purposes this optimizes at least as well as ImmutableJS, and there is no overhead from loading and using a dedicated library. However it does require extra boilerplate and manual updates to version tags each time something changes, and it can cause confusion if you forget to update a version tag or accidentally update the wrong one. Anyway, it is one alternative, but if you don't have a compelling reason not to use ImmutableJS for optimization I'd probably go with that. Of course it is perfect for undo/redo functionality too if that is a requirement.
- rymohr 11y ago
  Your approach sounds interesting. Ever write about it? The undo / redo gains of ImmutableJS quickly vanish when you're working with remote data and the leaked getters aren't fun. A little UUID juggling is worth it if it allows my components/reducers to work with plain old javascript objects and still get fast shouldComponentUpdates.
  - guscost 11y ago
    It's one of the ideas for shouldComponentUpdate that I wrote about here, but it's not described in a lot of detail: http://guscost.com/2015/05/27/react-js-and-flux-ideas-for-practical-applications/ http://guscost.com/2015/05/27/react-js-and-flux-ideas-for-pr... One of these days I'll put up another piece on Flux/React, and an example application to demonstrate an approach that doesn't have a lot of dependencies (not even ES6, for example). Also I have not run into any pitfalls using ImmutableJS yet apart from the extra overhead, so thanks for the heads up.