I'm getting some form of boxing during array access, even on the equiv branch.
Speaking of which: (type (+ 1N 1)) => clojure.lang.BigInt means that I'm using the correct branch, right? Here is a simple speed test comparing 3-element vectors using Java arrays, immutable deftype and mutable deftype: http://gist.github.com/459383 Using the equiv branch, I get * Java arrays: 18s * Immutable deftype: 10s * Mutable deftype: 2s * Plain Java: 2s Here is a profiler snapshot for the array case, where java.lang.Number.init(), java.lang.Double.init() and java.lang.Double.valueOf() take a significant chunk of the CPU time: http://i589.photobucket.com/albums/ss334/j-g-faustus/profiling/eqv-arrays.png >From a practical standpoint I guess it means that deftype is the way to go if you want fast numbers today. In this case even the immutable deftype was faster than mutable Java arrays, so you can be fast, idiomatic and thread-safe simultaneously. For the future, it would be nice if Java arrays were equally fast. There is unchecked-inc-int and -long, would there be room for an unchecked-aget/aset-int/long/double? Regards jf On Jun 30, 6:14 pm, David Nolen <dnolen.li...@gmail.com> wrote: > On Wed, Jun 30, 2010 at 10:19 AM, j-g-faustus > <johannes.fries...@gmail.com>wrote: > > On the equiv branch I don't see this at all. Also on the equiv branch most > of your type hints inside the fn are unnecessary. > -- 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
