Rich has done a lot of work to make sure that when you are working with
primitives, the JVM bytecode ends up being very similar to what Java would
generate. See http://clojure.org/java_interop#toc36

Thanks,
Stu

On Thu, Mar 12, 2009 at 6:20 PM, Howard Lewis Ship <hls...@gmail.com> wrote:

>
> Well, at some point I'll open up the code and check.  Though I'll be
> overly tempted to write some comments, fix the indentation and write
> some tests if I do!
>
> On Thu, Mar 12, 2009 at 2:36 PM, Jarkko Oranen <chous...@gmail.com> wrote:
> >
> >
> > 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
> > >
> >
>
>
>
> --
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to