On Dec 7, 2012, at 5:25 PM, Lee Spector wrote: > The test: I wrote a time-consuming function that just does a bunch of math > and list manipulation (which is what takes a lot of time in my real > applications): > > (defn burn > ([] (loop [i 0 > value '()] > (if (>= i 10000) > (count (last (take 10000 (iterate reverse value)))) > (recur (inc i) > (cons > (* (int i) > (+ (float i) > (- (int i) > (/ (float i) > (inc (int i)))))) > value))))) > ([_] (burn)))
Lee: I'm hoping you realize that (take 10000 (iterate reverse value)) is reversing a linked list 10000 times, each time allocating 10000 cons cells (or Clojure's equivalent of a cons cell)? For a total of around 100,000,000 memory allocations of small objects per call to burn? I know that this is just a bit of code for testing purposes, and not your real application, but do you really do that quantity of memory allocation versus arithmetic in your code (7*10,000 arithmetic operations for every 10,000*10,000 memory allocations?) I still believe there is an issue here with either the memory allocation or garbage collection implementations that we are seeing here that can hopefully be improved with some command line options to the JVM that I don't know yet, but I know that I have seen much bigger speedups in code that didn't do this much memory allocation versus non-allocating computation (e.g. the Computer Language Benchmarks Game Clojure programs). Andy -- 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