[Rd] Slow ttests in R-devel
jmc at research.bell-labs.com
Wed Jun 4 18:09:07 MEST 2003
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))
>  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.
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
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 M. Chambers jmc at 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
More information about the R-devel