Isn't that always the way, though? Build your program in a powerful, expressive language, then profile it, find the critical parts, and optimise them - where possible in the same language, and where that's too ugly/painful, drop down a layer to a lower level language.
I did lots of this in the late '80s - I wrote programs in C, found where they were slow, optimised the C where it was viable, and re-implemented the core bits in assembler. This was great for high performance on a single cpu architecture, but over the years CPUs got faster and CPUs changed - among other things they optimised differently, so speed tweaks for an 80386 were actually slower on a Pentium. I tend to think clojure is in a similar position - fast enough for the vast majority of things (ymmv of course - depending on what your domain is) and if you meet a situation like this where optimising the clojure becomes too ugly, you can drop down to Java (or indeed C!) - but you lose interoperability with ClojureScript, and hopefully in time language and VM improvements will make this less necessary. - Korny -- Sent from my geek device... Spelling mistakes can be blamed on Google Whatever the final performance achieved, the fact remains that the original Java code was much cleaner, simpler, and more comprehensible than the big ball of mud the performant Clojure version is turning into. I have my own piece of performance-critical code that I used to maintain and improve over a timespan of many months. I finally gave in and recoded the thing in Java. It took only a couple of hours and the result was nice, clean, idiomatic Java code, with completely predictable performance characteristics, as opposed to the Clojure version where it took many hours of staring at ridiculuously counterintuitive stacktraces in VisualVM to find what to optimize and how. The amount of code is about the same at either end. On Thursday, February 21, 2013 10:41:55 AM UTC+1, Christophe Grand wrote: I updated my answer on SO, with a deftype-based one that gives me an additional 30% boost. Whatever the final performance achieved, the fact remains that the original Java code was much cleaner, simpler, and more comprehensible than the big ball of mud the performant Clojure version is turning into. I have my own piece of performance-critical code that I used to maintain and improve over a timespan of many months. I finally gave in and recoded the thing in Java. It took only a couple of hours and the result was nice, clean, idiomatic Java code, with completely predictable performance characteristics, as opposed to the Clojure version where it took many hours of staring at ridiculuously counterintuitive stacktraces in VisualVM to find what to optimize and how. The amount of code is about the same at either end. On Thursday, February 21, 2013 10:41:55 AM UTC+1, Christophe Grand wrote: > > I updated my answer on SO, with a deftype-based one that gives me an > additional 30% boost. > > > On Tue, Feb 19, 2013 at 6:38 PM, Geo <ggrig...@gmail.com> wrote: > >> What about the call to .equals? >> >> >> On Tuesday, February 19, 2013 12:20:28 PM UTC-5, Marko Topolnik wrote: >>> >>> The difference between String[] and Object[] is that a member of the >>> former doesn't need a checked cast to String, but the latter does need one. >>> In the code under consideration, however, nothing specific to String is >>> used, so even in the Java code you can freely replace String[] with >>> Object[] and everything still works. >>> >>> If, on the other hand, you needed to invoke say *substring*, you'd see >>> a small penalty due to the checked cast operation. >>> >>> On Tuesday, February 19, 2013 5:52:31 PM UTC+1, Andy Fingerhut wrote: >>>> >>>> ^objects is a Clojure synonym for ^"[Ljava.lang.Object;". Note that >>>> there are such synonyms for only a few Java types, not everything, e.g. >>>> there is no ^strings. >>>> >>>> What you are hinting is that a1 and a2 are Java arrays of objects. I >>>> think this might speed up (aget a1 i) expressions, since it is known that >>>> a1 is an array of objects, but I'm not sure about that. I believe "under >>>> the hood" in the JVM all arrays of Objects are treated the same, regardless >>>> of whether those Objects are String, Integer, java.awt.Color, etc. >>>> >>>> Andy >>>> >>>> On Feb 19, 2013, at 8:46 AM, Geo wrote: >>>> >>>> One thing I don't get is that switching the type hints from >>>> >>>> [#^"[Ljava.lang.String;" a1 #^"[Ljava.lang.String;" a2] >>>> >>>> to [^objects a1 ^objects a2] didn't seem to have any negative impact on >>>> performance. Can anyone explain why hinting ^objects is just as good as >>>> specifying that it's an array of Strings? What are you hinting with >>>> ^objects that Clojure doesn't already know? >>>> >>>> -- >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@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+u...@**googlegroups.com >> For more options, visit this group at >> http://groups.google.com/**group/clojure?hl=en<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+u...@**googlegroups.com. >> For more options, visit >> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >> . >> >> >> > > > > -- > On Clojure http://clj-me.cgrand.net/ > Clojure Programming http://clojurebook.com > Training, Consulting & Contracting http://lambdanext.eu/ > -- -- 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. -- -- 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.
