The second one is slower because the (cb l) call is going via (fn [Object]) which then delegates to (fn [long]) rather than using (fn [Object]) directly. I believe it may be doing an extra cast as well, which would explain the extra 3ns of overhead.
In general, I've found primitive functions are very tricky to get working at maximum performance within higher order functions: they are mostly useful for direct calls with known arguments. If you really care about performance then you might find that using Java interfaces or abstract base classes works better: there are easier to type hint, it can give you a bit more control and doesn't have as many restrictions / strange edge cases. Also they work nicely for protocol dispatch. I use this technique quite a lot within vectorz-clj to squeeze the maximum performance out or low-level vector/matrix operations. Downside it that it isn't idiomatic Clojure..... but currently you have to live with that if you want maximum performance. On Wednesday, 24 April 2013 23:35:11 UTC+8, Alice wrote: > > (defn foo [^long l cb] (cb l)) > > (time > (dotimes [n 1000000] > (foo n (fn [l] nil)))) > > (time > (dotimes [n 1000000] > (foo n (fn [^long l] nil)))) > > "Elapsed time: 7.861 msecs" > "Elapsed time: 11.770973 msecs" > > > Why is the latter slower? > -- -- 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.
