Are you testing this inside of a lein repl (or any repl for that matter)? If so, compile it to a jar and run the jar directly via java -server -jar jarfile.jar. This could change your numbers a bit.
Timothy On Tue, Jun 2, 2015 at 11:08 AM, Mars0i <marsh...@logical.net> wrote: > I have an application using Java interop, in which I can define a class > using either deftype or defrecord. It has one field, containing an atom > containing a double, and a few methods. One of the methods is specified by > an interface defined in Java, and that method is called from Java. This > method is called many times in an inner loop. I don't use any of the extra > functionality provided by defrecord, but in otheri, similar programs, I > will. > > When I use defrecord, the speed of the program is about 25% of its speed > when I use deftype. This is a one-line change. I'm testing speed simply > by running the program for a long time, and timing it. I've done this test > repeatedly, so there's no reason to think the differences have to do with > other processes running on my machines. > > When I benchmark simple uses of defrecord and deftype using criterium, > they're about the same speed. > > Is there any obvious reason to think that there are situations--e.g. > method calls from Java--in which deftype would be expected to be > significantly faster than defrecord? > > I can construct a minimal example based on my program and post it here, > but I thought I'd check first whether there is something obvious that I > don't get. > > [The test I did using defrecord is below. I also replaced 'defrecord' > with 'deftype' and did the same test. I would think that the JIT compiler > wouldn't be smart enough to optimize away whatever differs between > defrecord and deftype, but maybe I'm wrong about that. > > (defrecord R [x y] > P > (incx2y [this] (reset! x (inc @y))) > (decy2x [this] (reset! y (dec @x)))) > > (def r (R. (atom 2) (atom 1))) > > (bench (def _ (dotimes [_ 50000000] (incx2y r) (decy2x r) r))) > ] > > -- > 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/d/optout. > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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/d/optout.
