It wouldn't be a first for me, either; I'm already accustomed to writing macros for performance. For example, unrolling writer.append loops, using "jassoc" as a Java HashMap replacement for assoc, and many similar tricks.
On this particular occasion, where the performance-critical code segment has gradually grown to over 100 lines, and where with each development iteration I had to set up profiling sessions, painstakingly work through VisualVM traces, devise hypotheses, try out solutions, etc., the point was reached where I called it a day and rewrote to Java. Not to say that having Java involved is any picnic: each change requires restarting the nREPL session, recompiling everything, reconnecting nrepl.el, reinitializing database connection and Lucene indexes, and so on. The pain is substantial but it feels like a relief nevertheless. On Friday, February 22, 2013 9:54:18 PM UTC+1, David Nolen wrote: > > Oh right, sorry, you don't want to pay for boxing the double. Yeah this is > the case where you'd want to go with a tuple. If this really was common in > my own code I would probably write a mutable tuple macro. But I totally > understand why someone else might just write the Java if they just want > performance and just don't want to bother. > > > On Fri, Feb 22, 2013 at 3:27 PM, Marko Topolnik > <marko.t...@gmail.com<javascript:> > > wrote: > >> On Friday, February 22, 2013 8:41:15 PM UTC+1, David Nolen wrote: >> >>> Er re: assigning stack based locals. Forget wasting time making a tuple >>> type, probably best to just do that with a small mutable array. This >>> worked ok for us when porting some Java persistent data structure code to >>> ClojureScript. >>> >> >> Again, must reuse the same array for all inner iterations to avoid >> allocation, GC, and cache misses. I need two Strings and one primitive >> double, so I'm actually looking at two arrays. The housekeeping overhead is >> just too much for my taste. That's why the rewrite into Java came as such a >> relief :) >> >> -- >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com<javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> 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+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- -- 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.
