Some perspectives (as someone who has been tuning this stuff a lot, from a core.matrix standpoint in particular)
On Saturday, 1 March 2014 13:02:26 UTC+8, bob wrote: > > Hi, > > Can I ask a newbie question about clojure performance? > > What make clojure performance slow than java?, it seems clojure has the > 1/4 performance compared to java in general, according to tests, some > cases it might be 1/10. the reasons I can think out are > > - the byte code is not efficient sometimes > - the byte code might not enjoy the jvm optimization > Sometimes a problem, though Clojure is not too bad at bytecode generation and the JIT will do most of the obvious optimisations for you. > - the reflection > This is extremely bad for performance, but luckily it is easy to avoid: - Always use *warn-on-reflection* - Eliminate every single reflection warning with type hints > - the immutable data structure > This is often a performance *advantage*, especially when you start dealing with concurrency and data-driven snapshot. In the few cases where it is a problem, you can always drop back to using mutable Java data structures or arrays - so this isn't ever really an issue. > - the abstract interface design > This doesn't actually cost that much. Interfaces on the JVM are extremely fast and very well optimised. In many cases, JIT optimisations make them just as fast as a static method call. > > The abstract interface like seq offers its power, but it is easy to drop > in the performance trap. > ISeq itself isn't too bad (it's just an interface, as above), but some of the implementations are a bit expensive. Lazy seqs for example are not so fast... and often you don't need the laziness. However most clojure.core functions produce lazy seqs by default. I wrote an "eager-map" replacement for "map" in my clojure-utils library to get around this problem > > And it seems to me that it is easy to write a slow clojure program, I know > the efficiency of code depends on coder, you can write the code faster than > java sometimes,but need to know a lot of deep thing and tricky, and > clojure is not the funny clojure any more. > > > Thanks > > There are also a couple of other general issues that are slightly problematic performance issues for Clojure that can make it noticeably slower than Java for a lot of typical code: 1) Dynamic var lookup - this is expensive because all var accesses need to go via a var dereference. This prevents many JVM optimisations, and if affects pretty much every non-inlined function call in regular Clojure code. Fixing this would require eliminating the var-based namespace model - something I've been experimenting with in my experimental language Kiss, which eliminates vars and uses immutable namespaces. This approach looks promising, but is a pretty radical change so not sure if it will ever get into Clojure itself. 2) Dynamic dispatch: If you look into the details, a lot of Clojure functions have an "Object" argument and end up doing a serious of instance? checks or other methods to achieve dynamic dispatch. This is expensive and unnecessary in many cases, since you can often prove that the argument must be of a specific type (e.g. java.lang.String). This is fixable, but would require smarter type inference in the Clojure compiler itself. Again this is something I'm experimenting with in Kiss, it might also be fixed in a future Clojure-in-Clojure compiler. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
