[gugagore]

Persistent data structures are, in my opinion, underrated. Not so much for every day programming tasks, but specifically for code that resembles planning/searching.

Here is one library I've heard of https://immutable-js.com/ . I don't know of others.

[throw868788]

I'm wondering if there is some inherit flaw in coding some data structures in Node/JS. Maybe this is just another case of the "Node tax"? Things like boxing, floating point number arithmetic, manual pop counts, array copying with bounds checks, etc would all go quite a far way to making for example the Map quite under performant by quite a significant factor especially with large collection sizes and hot loops. Have no idea what the Node runtime does/optimises for example the software version of PopCount encoded in the Immutable.js.

Having written persistent data structures in other lang's that are quite capable (170ns lookup 10,000,000 elements approx to give a rough guide) - yes it is an order slower than unordered hash mutable structures but often still faster than for example the mutable ordered ones I've tested with the advantage of still being immutable. This does benefit some scenarios where you want data sharing/cheap clones of data.

[mschaef]

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.)

[Quekid5]

That particular example seems to be a horrible misapplication of an ImmutableMap. That's not a map, that's just a record of values. (Well the 'board' member is a collection, but you get what I'm saying.)

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).

[panick21_]

Immutable JS is from Facebook.

Mori is the 'original' Clojure data-structures in Java Script.

https://swannodette.github.io/mori/