Are there are performance comparisons of Clojure on JVM versus CLR? Or maybe someone who has used both with performance-sensitive code can give some anecdotal comments?
-
1If it's performance sensitive maybe you want to use a native code solution as opposed to something running on either the CLR or JVM. – Onorio Catenacci May 31 '12 at 14:26
-
1I meant performance-sensitive bound by what Clojure supports. I'm particularly interested because it seems the CLR version uses the DLR. Does Java have an equivalent? I'm wondering how much the JVM-specific and CLR-specific tech (like the DLR) impact performance. – Suraj May 31 '12 at 14:53
-
I understand what you're getting at and I'd say that @mikera has answered your question but it does seem a bit premature to worry about relative performance of CLR vs. JVM when there are so many other issues with that choice. I mean the libraries present in the CLR library set vs. those present in the JVM libraries, especially if you're building something on Windows, should be a larger concern than relative performance. – Onorio Catenacci May 31 '12 at 15:08
-
Actually none of this is a real concern. I'm just asking out of academic curiosity =) I'll keep this question open with the hopes that someone with CLR experience can chime in. – Suraj May 31 '12 at 15:59
2 Answers
The performance of Clojure JVM is better than that of Clojure CLR. I don't have explicit benchmarks to point to, but I have a lot of experience doing compilation and running tests in both environments and the difference is obvious.
There are several factors involved in the difference. Some are being worked on. Some are related to JVM vs CLR perf differences and hence beyond the means of the ClojureCLR developers to address.
(1) Compilation of Clojure code to the platform Intermediate Language.
At the most basic level, the IL generated is almost identical. However, design choices forced by some limitations of the Dynamic Language Runtime result in each function definition creating an extra class and function invocations to have an extra method call. Version 1.4 of ClojureCLR (coming soon) eliminates the use of the DLR for most code generation. (The DLR will still be used for CLR interop and polymorphic inline caching.) At this point, generated code will be substantially the same as the JVM version. Startup time has been reduced by 10% and simple benchmarks show 4-16% improvements over version 1.3. More details here.
(2) Startup time Clojure JVM starts significantly faster than Clojure CLR. Most of this is traceable to the JVM being able to selectively load class files (versus the CLR loading entire assemblies) and differences in when JIT compilation occurs. However, if ClojureCLR is NGEN'd, startup times are really fast. More details here.
(3) JVM versus CLR performance Some attention has been paid to making ClojureJVM work well with HotSpot compiler optimizations. I don't have explicit proof, but I'm guessing that HotSpot just does a better job on things like inlining in compiled Clojure code versus the CLR JITter. It is fair to say that no attention has been paid to how to make ClojureCLR take better advantage of the CLR JITter.
The release of ClojureCLR 1.4 will provide a good opportunity for some benchmarking.

- 321
- 1
- 3
-
Has the story changed with the release of .NET 5/6 (I'd love to try out Clojure CLR once again)? Thanks! – Cosmin Sontu Oct 22 '21 at 09:11
-
1The changes mentioned in item (1) were made. Startup time is better, but still not as good as the JVM. In fact, .Net Core and .Net 5/6 have made startup times worse. The System.Reflection.Emit.AssemblyBuilder.Save() method was removed, getting rid of AOT-compilation of the Clojure source files that define much of the Clojure environment. Thus that code has be loaded from source and compiled at startup. Work is being done on the ClojureCLR compiler to fix this problem. With tiered compilation, the startup times should improve dramatically. Stay tuned. – David Miller Dec 12 '21 at 20:39
I've not really used the CLR version so can't fully answer your question.
However it is worth noting that most of the optimisation / development effort so far has gone into the mainline JVM version of Clojure. As a result you can expect the JVM version of Clojure to perform considerably better at present in most situations.
Clojure on the JVM is already one of the fastest dynamically typed languages around - from the benchmarks game page Common Lisp is the only dynamically typed language which is (marginally) faster.
Over time I'd expect the Clojure JVM/CLR gap to narrow as both versions tend towards the performance of their host platforms. But right now, if performance is your key concern, I'd definitely recommend the JVM version (as well as performance, the JVM version is also likely to be better for overall maturity, library availability and cross platform support).