|
|
|
|
|
|
by mschaef
1652 days ago
|
|
|
My experience with ImmutableJS was to remove it and see performance go up by a factor of 100-200. https://github.com/mschaef/react-matchstick/commit/070802b69... This was something of a worst case scenario (and it was five years ago, so presumably things have gotten better) but it still underscores the need to carefully consider these tools before adopting them. Do they really offer enough (to your application) to be worth the associated costs in readability, performance, etc. If the goal is to prevent mutation, maybe there are better ways to do that. If the goal is to really accelerate, it's worth testing. (At the very least, Clojure's vectors seem unlikely to provide a benefit if you're working with vectors of len<32.) |
|
|
I'm not surprised you saw huge speed up... I mean the original is looking up record fields by their name at runtime. That's bound to be extremely slow because it's basically impenetrable to the JIT optimizer.
In this case doing it the "immutable way" would be to create a data object, freeze it, instead only creating copies (themselves frozen) with individual fields changes as appropriate.
I do wonder how it would have performed if you'd removed the outer 'sx', 'sy', 'board' map layer and kept the 'board' as an ImmutableList (or whatever).