Slow ttests in R-devel
Some revisions were committed this morning to R-patched that appear to fix the problems with caching methods, which apparently were the cause of the slow-downs. The test I've been using for caching runs Doug & Saikat's lme example from lme4. See attached file. The same style test could be used for any particular expression. There are still a couple of peculiarities -- for some reason it takes 3 executions of some expressions involving callNextMethod to cache everything. And, of course, other tests may raise new issues. But Doug and Saikat have done a good job of using lots of features! Many thanks. The current code passes check-all here. Please let me know of any problems. I'll be away the rest of today, but back tomorrow. John
John Chambers wrote:
Jeff Gentry wrote:
On Wed, 4 Jun 2003, John Chambers wrote:
There was a bug leading to non-caching of methods, in the r-patched code from a few days ago. A branch update would have put the changes into R-devel also. The problem has been partly fixed in the current code committed to R-patched (and some further fixes are in the works).
Actually, I realized that the particular R-pached I was using was from May 23. I used my June 4th version of R-patched (aka R-1.7.1 beta) and it matches my June 4th version of R-devel, more or less:
system.time(genefilter(eset, gf))
[1] 79.27 3.98 85.24 0.00 0.00 But, my 2003-05-23 version of r-patched produces a value that is roughly half of that. Not sure if that helps out at all, but the current r-patched and r-devel is definitely slower in this then it was about a week and a half ago. -J
Right. The fix committed earlier today caught some of the non-caching, but there are still some cases that are slipping through. So it matters "when" on June 4 the code was sampled. But either way, not all the problems are yet caught. Fortunately, this has finally got me to instrument some checks that method selection stays in the C code on the second time through an expression. By tomorrow morning, there should be a committed version that has no unneccessary S-level method selection (at least on my tests, using Doug & Saikat's lme4 code). It would be very helpful if you could check again after I send some mail around. John -- John M. Chambers jmc@bell-labs.com Bell Labs, Lucent Technologies office: (908)582-2681 700 Mountain Avenue, Room 2C-282 fax: (908)582-3340 Murray Hill, NJ 07974 web: http://www.cs.bell-labs.com/~jmc
______________________________________________ R-devel@stat.math.ethz.ch mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
John M. Chambers jmc@bell-labs.com Bell Labs, Lucent Technologies office: (908)582-2681 700 Mountain Avenue, Room 2C-282 fax: (908)582-3340 Murray Hill, NJ 07974 web: http://www.cs.bell-labs.com/~jmc -------------- next part -------------- library(lme4) example(lme) checkNoSelect <- function(expr) { trace(MethodsListSelect, quote({message("Calling method selection when the method should have been cached: ", deparse(substitute(expr))); browser()}), at = length(as.list(body(MethodsListSelect)))) on.exit(untrace(MethodsListSelect)) expr } checkNoSelect(example(lme))