[Rd] Slow ttests in R-devel

[John Chambers]

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 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
> 
> ______________________________________________
> R-devel at stat.math.ethz.ch mailing list
> https://www.stat.math.ethz.ch/mailman/listinfo/r-devel

-- 
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
-------------- 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))