David pointed out what should have been the obvious overhead (I'll blame it on being up at 2am), and Nicolas pointed out the specific problem.
Compare: user=> (time (doseq [x (range 100000)] (bit-shift-left x 1))) Reflection warning, NO_SOURCE_PATH:4 - call to shiftLeft can't be resolved. Reflection warning, NO_SOURCE_PATH:4 - call to shiftLeft can't be resolved. "Elapsed time: 3572.769 msecs" nil user=> (time (doseq [x (range 100000)] (bit-shift-left (long x) 1))) "Elapsed time: 19.585 msecs" user=> (time (let [i (Long. 1)] (doseq [x (range 100000)] (bit-shift- left x i)))) "Elapsed time: 25.228 msecs" nil So now that literals are long primitives, there are areas where the inlined static methods' param types no longer align with the arg types, triggering reflection and a performance hit. Of course *warn- on-reflection* reveals the problem, but that may be cold comfort to extant systems wishing to move to 1.3. On Oct 1, 6:01 am, Nicolas Oury <nicolas.o...@gmail.com> wrote: > There is no java definition for (Number, long) or (Number, int). > > As 1 is now a primitive, I think it cannot find any corresponding function. > > Strangely, putting 1M or (num 1) might be faster. > > Can someone try? > > > > > > On Fri, Oct 1, 2010 at 10:28 AM, David Powell <djpow...@djpowell.net> wrote: > > >> So, if it is true that range produces objects and dotimes produces > >> primitive longs, then I believe that it is the odd interaction between > >> bit-shift-left's inlining and long objects (as opposed to primitives) > >> that is causing the disparity in your measurements, not something > >> inherent in the mechanism of doseq vs dotimes. > > > [Oops - sorry for the blank email] > > > I notice, that If you enable *warn-on-reflection*, you can see that a call > > using the inline version gets compiled as a reflective call. If you remove > > the inline definition, no such reflective call is made. Not sure why this > > is. > > > -- > > Dave > > > -- > > 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 > > -- > Sent from an IBM Model M, 15 August 1989. -- 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
