Hacker News Reader

Comment by skybrian | Hacker News Reader

People often say that immutable data structures are fast because pointer comparison is fast. But as soon as you do any transformation, even something as simple as map(), the pointers all change. So it seems like the speed of pointer checks is only relevant in cases where you're not doing anything interesting with the data.

In particular, if you need to apply any transformation to your model before displaying it in a view, it's not going to be a fast pointer check - you need to do dirty checks on all the elements just like you would with mutable data structures.

View on HN

Sure you would need to do go one level deeper if the top level is different, but you can still use pointer equality at the lower levels

  immutableEq(a1, a2) {
    return (a1 === a2) || all(mapPair(a1, a2, immutableEq))
  }

Now if you update the value of a single element in the array a2, you would not have to check all the elements in depth (only their references):

  a1 = Immutable.List(el1, el2, el3, el4, el5)
  a2 = a1.set(2, Immutable.Map({hello: "world"}));
  immutableEq(a1, a2) // all but el3 compared by reference equality

To generalize. If a change occurred at a [hot] path of a [deeply nested] map, then only [React] components that depend on the data at any subpath would perform the dirty check (i.e. executing shouldComponentUpdate) to re-render the component.

In your example you're just changing one element and leaving the rest the same - a pretty trivial transformation. If you're applying map() to a list then all of the elements change.

If you have a pipeline then it's going to result in everything downstream re-running, unless you compare the output of the map() transformation to the previous value, like some build systems do.

Or alternatively, run all the major data transformations necessary to get from data to VDOM from the render function, passing as much as possible of the original data to the bottom-most components.

That depends on your program. If your function is pure, you can memoize, and then it will be a fast pointer check.

True that.

This conforms with my understanding as to why Clojure is slowish. That being said, I don't really understand why Haskell is seen as fast and Clojure is seen as slow (I am ignoring JVM warm-up times here).

Do they use fundamentally different algorithms under the covers?

Clojure isn't very slow. It's possible to write Clojure with identical performance of java (though this isn't idiomatic, and avoids some of Clojure's nicer features).

Clojure's immutable datastructures are ~25% slower than standard java, but also eliminate entire classes of bugs.

I'm not familiar with Haskell's immutable data structures, but I'd be very surprised if there's an optimization that hasn't been adopted by Clojure. Rich Hickey put a lot of work into optimizing them.

Haskell's GHC is a super clever optimizing compiler with a garbage collector built around the sort of memory pressure that arises when you've got tons of immutable data. Some of GHC's brand of speed comes from the super optimization bits where GHC automatically intuits out a mutating, low level, primitive loop out of your high level description. Some comes from loads and loads of tuning. Clojure cannot benefit from the latter because JVMs are tuned differently and cannot benefit from the first because it has less good transformation semantics.

Reply on news.ycombinator.com