On Sun, Jan 4, 2009 at 4:50 PM, <l...@stat.uiowa.edu> wrote: > On Sun, 4 Jan 2009, Stavros Macrakis wrote: >> On Sat, Jan 3, 2009 at 7:02 PM, <l...@stat.uiowa.edu> wrote: >>> R's interpreter is fairly slow due in large part to the allocation of >>> argument lists and the cost of lookups of variables,
I'd think another problem is call-by-need. I suppose inlining or batch analyzing groups of functions helps there. >>> including ones like [<- that are assembled and looked up as strings on >>> every call. >> Wow, I had no idea the interpreter was so awful. Just some simple >> tree-to-tree transformations would speed things up, I'd think, e.g. >> `<-`(`[`(...), ...) ==> `<-[`(...,...). > 'Awful' seems a bit strong. Well, I haven't looked at the code, but if I'm interpreting "assembled and looked up as strings on every call" correctly, this means taking names, expanding them to strings, concatenating them, re-interning them, then looking up the value. That sounds pretty awful to me both in the sense of being inefficient and of being ugly. >> I'd think that one of the challenges will be the dynamic types --... > I am for now trying to get away without declarations and pre-testing > for the best cases before passing others off to the current internal > code. Have you considered using Java bytecodes and taking advantage of dynamic compilers like Hotspot? They often do a good job in cases like this by assuming that types are fairly predictable from one run to the next of a piece of code. Or is the Java semantic model too different? > ...There is always a trade-off in complicating the code and the consequences > for maintainability that implies. Agreed entirely! > A 1.5 factor difference here I find difficult to get excited about, but it > might be worth a look. I agree. The 1.5 isn't a big deal at all. -s ______________________________________________ R-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.