I was worrying about https://github.com/hugoduncan/criterium/issues/19 but actually these tests are not nearly fast enough to cause problems.
I reran the last benchmark without dotimes and the results look pretty much the same - https://gist.github.com/jamii/6607031 I'm still a little worried about adding more frames onto the stack but it only really matters inside mutually-recursive parsers and I suspect I'm going to have to trampoline those anyway. On 18 September 2013 06:23, Jason Wolfe <ja...@w01fe.com> wrote: > I've found similar things with compiling schema validators. Be careful with > doseq benchmarks like this though, if you aren't careful hotspot can > completely eliminate parts of the computation as dead code if it can infer > the results aren't used. Criterion has a neat trick for making sure this > can't happen, IIRC. > > > On Tuesday, September 17, 2013 10:00:46 AM UTC-7, Jamie Brandon wrote: >> >> For larger patterns, the staged version is actually significantly faster: >> >> https://gist.github.com/jamii/6597235 >> >> On 17 September 2013 16:29, Jamie Brandon <ja...@scattered-thoughts.net> >> wrote: >> > I ran a little benchmark comparing different implementations of a toy >> > pattern matching protocol: >> > >> > https://gist.github.com/jamii/6595850 >> > >> > I'm surprised to find that the staged version is not significantly >> > slower than the compiled version. Now I'm wondering whether this is >> > feasible on a larger scale. Can I always rely on those fns being >> > inlined? Is there some magic threshold on closure nesting where >> > suddenly there will be inlining and I will blow up my stack? >> > >> > More generally, how can I find out this sort of thing? There seems to >> > be very little hard information on what optimisations hotspot will >> > reliably perform. >> > >> > This looks like it could be useful - >> > >> > http://mechanical-sympathy.blogspot.co.uk/2013/06/printing-generated-assembly-code-from.html >> > - but I'm not sure how I would make that work with clojures class name >> > mangling for closures. -- -- 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.
