views:

1734

answers:

5

Edit: The Clojure benchmarks are up on the Benchmarks Game.

I have made this question community wiki and invite others to keep it updated.


Is anyone aware of benchmarks of Clojure's performance?

I have done some of my own (although nothing too formal) and it didn't fair too well in comparison to other functional languages (tried Haskell and OCaml). But how does it look compared to Java or another language on the JVM (e.g. Scala)? And how does it compare to other Lisps?

There was some discussion on the Computer Language Benchmarks Game forum about adding Clojure on there, but nothing has been done yet.

Edit: I'm going to continue to add to this as I find more:

@igouy pointed out that the benchmark scripts for clojure are being created by jafingerhut on github.

Two very relevant threads from the Clojure discussion group:

And separately, these blog posts:

And lastly, a related question on stackoverflow:

Most of these discussions lead me to think that Clojure's performance is very favorable in comparison to other languages running on the JVM, although there is no doubt that it can be very difficult to come to a broad conclusion when comparing languages because their performance can vary dramatically dependent on the task.

Edit:

Lau Jensen just posted a great discussion about benchmarking with JVM languages on his blog: "Getting benchmarking right".

+6  A: 

This is an important question that just about everyone thinks about before considering clojure. Its also a hard question even for mature languages that are not adding things, like chunked sequences, that radically change the performance of some specific (though common) tasks. I found some good thoughs in this thread. Many of the benchmarks you find will be related to previous versions of both java and clojure so its unlikely that anyone can find "really good benchmarks".

I great question to ask your self here is Is Java fast enough. This is a precondition to clojure being fast enough. If you can convince your self that the answer to this question is yes then it is safe to proceed in Clojure and implement the parts that your profiling identifies as bottle necks in Java. Because you have a failback language with well known performance It will generally be safe to go with Clojure.

Arthur Ulfeldt
+7  A: 

See jafingerhut / clojure-benchmarks

iirc the current clojure implementation has not been focussed on performance, but the next version supposedly will.

igouy
+2  A: 

You might also be interested in the concur.next serie from Tim Bray. He discusses some performance issues.

ewernli
+1  A: 

Clojure will never be able to match a Scala program that takes full advantage of mutability in an algorithm that's benefitted by it. There's also the fact that Clojure is a dynamic language, which, presently, isn't very well supported by JVM.

On the other hand, Clojure excels at enabling parallel, asynchronous and distributed algorithms, and immutable algorithms generally speaking.

So, if you want (mostly) immutability and multicore efficiency, Clojure will make those much easier to achieve. If your algorithms really, really need to heavily use mutability for efficiency, then Scala will make those easier.

Anything in between, it likely won't matter either way.

Daniel
clojure can work with java arrays or the java collection and you can use type hints so it maybe hard but it is possible if you REALLY need it.
nickik
+6  A: 

For performance questions please refer to this blogpost:

http://meshy.org/2009/12/13/widefinder-2-with-clojure.html

This shows a Clojure implementation of the WideFinder2 challenge which is faster than both Java, Scala and single threaded C. Compare with official times.

Regarding Daniels remark that Clojure will never be faster, we see that its obviously incorrect based on the results above. Mutability is faster than immutability which is Clojures default, yet Clojure allows for local transients (ie. temporarily mutable data), so that one can achieve optimal speed.

Refer to clj-me.cgrand.net for many optimization techniques.

In conclusion: Clojure can be as fast as you would like it to be while still allowing you to maintain a simple elegant and robust codebase, almost a unique combination.

Lau Jensen
That's an interesting read! I'm not sure that the conclusion that "Clojure can be as fast as you would like it to be" holds from that benchmark. The author did a lot of optimization of Clojure code and admits that the same tricks would work for Java and Scala (e.g. a lot of it was avoiding Java's String.split!). It speaks more to the virtues of repeated optimization. It does show that one can be perfectly comfortable with using Clojure for a wide variety of tasks, though.
Rex Kerr