Clojure may not find much popularity since it lacks sufficient Clojure-based libraries and frameworks, compared to other applications worth consideration. The lisp syntax of Clojure is also more difficult to read, and therefore could stir being unfamiliar with the tool.
In principle, Clojure can be just as fast as Java: both are compiled to Java bytecode instructions, which are executed by a Java Virtual Machine ... Clojure code will generally run slower than equiva- lent Java code. However, with some minor adjustments, Clojure performance can usually be brought near Java performance.
Idiomatic Clojure without sacrificing performance This made me curious as to how fast it could be made if I really tried, and was able to get nearly 30x more1 by optimizing it. Clojure is definitely fast enough for everything I've done professionally for six years.
So, the most popular modern Clojure implementation uses the Java Virtual Machine. This enables simple interaction with Java libraries, creation of Java objects and using the Maven repository. Java platform's maturity and the huge ecosystem provide many benefits for Clojure developers.
See jafingerhut / clojure-benchmarks
iirc the current clojure implementation has not been focussed on performance, but the next version supposedly will.
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.
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.
You might also be interested in the concur.next serie from Tim Bray. He discusses some performance issues.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With