Hacker News Reader

Comment by brabel | Hacker News Reader

> In our benchmarks, the Clojure version underperformed by about 9-13% when comparing peak throughput.

The performance difference between Clojure and the pure Java implementations was much smaller than I'd thought. Quite amazing for a dynamically typed language to get so close to Java in performance, to be honest.

The ring-clojure performance was much lower than the Java equivalent, but that's expected because de-serialization can be A LOT faster when you use static types for guiding parsing (e.g. cache the string keys and never allocate object keys, maybe small values that are common as well). I wonder if Clojure contracts could be used for the same tricks.

View on HN

Could you expand on the last paragraph? I have trouble following it

When using a "mapper", the user tells the library up-front what objects will be used for holding the JSON data. You can do all kinds of optimizations if you know the shape of the data and what objects will need to be allocated in order to hold it, before the JSON actually arrives.

In my testing I couldn't tell the difference between Java and Clojure performance solving the same problem. Probably because Clojure is lazy in many cases (or the implementer can choose a lazy implementation) where Java has to be eager all the time.

That's not surprising given that they rewrote all the middleware in Java and the Clojure part was just a very thin wrapper around vertx. And that's fine, it's what makes Clojure usable in production, but the vast majority of Clojure users bash Java all the time, take this libraries for granted and ignore the fact that a big range of software for the JVM is better written in Java than in Clojure.

Because they literally re-wrote the majority of it to use vert-x directly.

The clojure pieces are nothing more than a wrapper which is exactly what clojure is best used for.

Reply on news.ycombinator.com