A clojure program written in "canonical" style will usually be slower than the equivalent "canonical" java program (as long as canonical != enterprisey canonical), if only because canonical Clojure uses immutable datastructures and therefore spends quite a bit of time churning memory but Clojure lets you type-hint programs (to generate more type-tight bytecode, closer to what statically typed Java would provide), use Java mutable types and alongside compile-time metaprogramming that can be used to generate code which will likely be as efficient as tight Java code: http://www.learningclojure.com/2010/09/clojure-faster-than-m...
A bigger drawback to Clojure, in my experience, is that error messages are complete shit (most errors will yield stack traces to compiled bytecode, so you get java traces with a layer of obfuscation in that they're tracing the bytecode generated by clojure). The same issue exists when trying to improve performances, you get performance counters for java bytecode and have to match them to clojure code "by hand".
You may know this, but Clojure's immutable data structures don't spend near as much time churning memory as they would if they were implemented naively. Change one element of a sequence, and in your new sequence all the unchanged elements will reference the same memory locations they did before.
Sure, but you'll still need to reallocate all the tree path leading to the changed value, there's only so much immutable datastructures can share. And this does result in signifiant churn compared to an object/imperative system where most of the manipulations mutate existing objects (with very little allocations or deallocations comparatively).
Comments
A clojure program written in "canonical" style will usually be slower than the equivalent "canonical" java program (as long as canonical != enterprisey canonical), if only because canonical Clojure uses immutable datastructures and therefore spends quite a bit of time churning memory but Clojure lets you type-hint programs (to generate more type-tight bytecode, closer to what statically typed Java would provide), use Java mutable types and alongside compile-time metaprogramming that can be used to generate code which will likely be as efficient as tight Java code: http://www.learningclojure.com/2010/09/clojure-faster-than-m...
A bigger drawback to Clojure, in my experience, is that error messages are complete shit (most errors will yield stack traces to compiled bytecode, so you get java traces with a layer of obfuscation in that they're tracing the bytecode generated by clojure). The same issue exists when trying to improve performances, you get performance counters for java bytecode and have to match them to clojure code "by hand".
You may know this, but Clojure's immutable data structures don't spend near as much time churning memory as they would if they were implemented naively. Change one element of a sequence, and in your new sequence all the unchanged elements will reference the same memory locations they did before.
Sure, but you'll still need to reallocate all the tree path leading to the changed value, there's only so much immutable datastructures can share. And this does result in signifiant churn compared to an object/imperative system where most of the manipulations mutate existing objects (with very little allocations or deallocations comparatively).