[R] .C and DUP=TRUE versus .Call

Prof Brian Ripley ripley at stats.ox.ac.uk
Thu Sep 7 15:46:55 CEST 2000

> Date: Thu, 7 Sep 2000 13:29:21 +0100 (BST)
> From: Jonathan Rougier <J.C.Rougier at durham.ac.uk>
> I have a piece of C code that uses R_alloc, and so I set DUP=TRUE in the
> call using ".C".  As I understand it this takes a copy of each object
> passed to my function.  If these objects are large then this could be
> expensive.  My question is, if I rewrote the code to use .Call, would I
> avoid this duplication by using the objects themselves (they are not
> modified in the code) rather than copies?

.C with DUP=TRUE (the default) copies the objects on the way in and on
the way out.  Incidentally, the first argument against DUP=FALSE,

     There are three important dangers with `DUP=FALSE'. The first is
     that garbage collection may move the object, resulting in the
     pointers pointing nowhere useful and causing hard-to-reproduce

is no longer true in the development version, which has a non-moving
garbage collector.

If your code does not modify any of the arguments, how does it do anything
useful?  Non-R side-effects like printing?

The short answer is that I would use .Call for things like this.
However, if I had a .C version only if I found it necessary.  The
experience with Svr4 (which is cleverer at not copying and allows
selective copying of .C arguments) is that the copying is rarely
expensive enough to think about compared to doing things to large objects.
(The development version can increase workspace for a temporary
copy as required.)

Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272860 (secr)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

r-help mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-help-request at stat.math.ethz.ch

More information about the R-help mailing list