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.
On Friday, February 22, 2013, David Nolen wrote: > On Fri, Feb 22, 2013 at 2:06 PM, Marko Topolnik > <marko.topol...@gmail.com<javascript:_e({}, 'cvml', > 'marko.topol...@gmail.com');> > > wrote: > >> >> Fair enough. My point was simply that Clojure implementations have a >>> small learnable subset that performs well when performance is desired - >>> primitives, loops, arrays, deftypes, etc regardless of host. It's >>> unfortunate that the host, in this case the JVM, requires quite a bit of >>> thinking about type hints and casts. I think most of the challenges around >>> are writing fast Clojure JVM code lie here. I note these issues are not >>> present in ClojureScript ;) >>> >> >> OK, but does that mean that at the end of the day, optimized >> ClojureScript performance is head-to-head with optimized JVM Clojure in a >> desktop/server side application? >> > > I don't think we can ever really be head-to-head and performance varies > between JS engines. V8 is particularly good - not surprising since it's > from the same folks who worked on HotSpot. > > That, we try to get the performance of ClojureScript on V8 as close to > Clojure on the JVM as we can without sacrificing performance on the other > engines. I think we're doing OK and we're improving constantly. > > >> I'll give you one specific item that I keep tripping upon: the lack of >> reassignable, stack-based locals. Without them I can't efficiently get more >> than one value out of a loop. Another item is that I can get zero primitive >> values out of a loop. How do you cope with those? >> > > Some ideas for the first point: > > * atoms > * implement efficient tuple type which uses mutation for multiple value > return > > I suspect the second option will be pretty fast. Annoying, but that's a > tradeoff with Clojure's mostly functional design. > > Second point, I think 1.5.0 addresses that to some degree thanks to > Christophe. > > >> When on the subject, the times are getting ripe for a full-length book >> not about how handsome and elegant and FP-y Clojure is (we have plenty of >> those), but a "terrorist's handbook" on writing performant Clojure. Can you >> recommend any current material in that direction? >> >> -Marko >> > > Heh, I always point out test.benchmark - > http://github.com/clojure/test.benchmark. There's some horrifying stuff > in there ;) > > David > -- -- 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.