On Mar 12, 11:15 pm, Howard Lewis Ship <hls...@gmail.com> wrote: > I have to wonder a bit about the ability to optimize. Everything > boils down to one of the seven or so basic forms. That's a lot of > function calls to do even small things, like adding numbers. You might > think that simple math would be optimized and inlined, but it isn't: > > Clojure > user=> (doc +) > ------------------------- > clojure.core/+ > ([] [x] [x y] [x y & more]) > Returns the sum of nums. (+) returns 0. > nil > user=> (ns clojure.core) > #<Namespace clojure.core> > clojure.core=> (defn + [x y] (* x y)) > #'clojure.core/+ > clojure.core=> (+ 3 5) > 15 > clojure.core=> > > This implies, to me, that Clojure is doing a full functional call, > with dynamic lookup via the namespace, even for +.
I think this is mistaken. Sure, for (+ foo bar) calls in the repl Clojure will do a full lookup, but if you have addition in a tight loop, the JVM should notice this and optimise it further. (I think Clojure also does some kind of caching.) You can also use type casts to make clojure use primitive instead of boxed math, bringing performance very close to Java. Now, it's probably true that the most straightforward Clojure implementation of an algorithm is likely not quite as fast as the Java equivalent, with a few tricks, you can often get pretty close. I don't have very in-depth knowledge of how Clojure handles these performance issues, but I believe your assumption is overly pessimistic. :) -- Jarkko --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
