On Tue, May 17, 2011 at 3:15 PM, Alexander Bertram <[email protected]> wrote: > > Great question! > > FYI, this is renjin's implementation of a Thunk or "Promise" as it's > called in R. The only difference > is that the context needs to be provided to access the variables that > were in scope when the thunk was created. > > http://code.google.com/p/renjin/source/browse/trunk/core/src/main/java/r/lang/Promise.java > > My question for the JVM-niks out there is how feasable is it create a > new jvm class for each thunk or function value? > When you write a function in scala or clojure, does this get compiled > into a new, separate class?
I don't know about Scala, but I know that in ABCL it does get compiled to a new class, and I think in Clojure it's the same. > I know invokedynamic will solve a lot of these problems, but in > targeting java 6, is it worth economizing on the number of class, > using for example reflection to dispatch a function call to a static > method? It depends. Reflection impacts very negatively on runtime performance. Having a great number of classes consumes more memory and makes startup slower (if you're loading a lot of them at startup), but should be otherwise ininfluent on performance (gurus, please correct me if I'm wrong). So at compile-time it's generally better to generate classes than to generate code that uses reflection. Generating new classes on the fly at runtime, instead, is certainly slower than reflectively calling a method, so it may make sense for one-off functions that call pre-existing code to use reflection rather than generate a new class that will be subsequently thrown away. However, that seems to be a pretty narrow case that's not worth addressing - but I don't know how functions are typically used in R, so I can't really comment about that. Alessio -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
