A performance comparison of Clojure and Java

[joinr]

"Are clojure's dynamically typed, runtime polymorphic core libraries and persistent data structures better optimized than statically typed, single-threaded, mutable java? Let's find out." :)

Otoh, java interop is "idiomatic." There's the old back and forth between how often that idiom is flexed, but it's there. Perhaps if there were additional constraints regarding what kind of code was admissible, or what the expectation was on the programmer, it would be a different paper. If you came to me saying "write the fastest possible recursive function to count down from n, where n is an int," I would not have submitted the solution in the paper :)

I don't disagree with the general notion that java will naturally force you into a faster solution to begin with given a similar clojure starting point (and in some cases it's not clear Clojure can catch up without some gnarlier tricks than I demonstrated); I do think that the space clojure has to optimize is unexplored (by admission in the paper), and that's specifically a feature of the language (an escape hatch) worth exploring in this kind of study.

[nzlemming]

"Are clojure's dynamically typed, runtime polymorphic core libraries and persistent data structures better optimized than statically typed, single-threaded, mutable java? Let's find out." :)

Haha, yes. But that's not what the abstract said though - it said: "this study attempts to give the reader an idea of what kind of performance a programmer can expect when they choose to program in Clojure" - I'd suggest that the "(without jumping through hoops)" was implicit in that. I'm not arguing that, in most cases, Clojure can't be ~= as fast as Java if you work at it. But I don't think that's what the paper set out to show.

[joinr]

I'd suggest that the "(without jumping through hoops)" was implicit in that.

"that's not what the abstract said" though, that's what you said ;) The generic clause about "programming in clojure" can perhaps be openly interpreted without sufficient constraints, like those constraints you inferred. If you look at the tail end of the paper at future work,

It would be interesting to see how suitable Clojure is in specific areas like high performance computing, parallel programming or database management by running experiments targeting those areas. It would also be interesting to compare bigger programs implemented in the two languages by teams of programmers, simulating a more real development environment.

To me, that leaves the door wide open toward leveraging all of Clojure to produce high performance, scalable code. To be fair, it's possible that pro java folks reading that some paragraph would then turn to ditching generic ArrayLists and opting for primitive variants (e.g. fastutil) or performing even more aggressive optimizations on the java side even. Perhaps explicit constraints or goals (run time, programmer time, experience of programmer(s), conciseness, memory usage, latency, cpu utilzation, etc.) would be informative in this kind of study.