[Rd] number of copies

[Simon Urbanek]

On Oct 3, 2011, at 2:43 PM, Terry Therneau wrote:

> 
> On Mon, 2011-10-03 at 12:31 -0400, Simon Urbanek wrote:
>>> Thanks.  I was hoping that x[,sorted] would act like "double(n)"
>> does in a .C call, and have no extra copies made since it has no local
>> assignment.
>> 
>> Yes it does act the same way, you get an extra copy with double(n) as
>> well - there is no difference.
>> 
> 
> That is surprising.  This is not true of Splus.  Since Chambers mentions it as a specific case as well (Programming with Data, p421) I assumed that R would be at least as intellegent.  He also used the unset() function to declare that something could be treated like double(n), i.e., need no further copies. But that always looked like a dangerous assertion to me and unset has disappeared, perhaps deservedly, from R.
> 

Ok, let me clarify - there are two entirely separate issues: one issue is to avoid duplication of closure arguments in the duplicate() sense -- and that has to do with the reference count and closures in general. The other is duplication in the .C() call which is entirely separate.

If you call
.C("foo", double(n))
then the double(n) object doesn't get duplicated in the call, because it has no references [other than the frame], so there is no duplicate() call on it, but .C will still create a duplicate double* object to pass to the C function because of DUP=TRUE. Then a new R object is created for the result from that double* array.

For comparison, in .Call you would use allocVector(REALSXP, n) and thus avoid two copies.

You can try to avoid that with .C(..., DUP=FALSE) but you'll be treading on eggs, because you can't check NAMED or call duplicate() yourself in C code for cases that may need it, so have to be very, very careful to not modify something inadvertently (this has been a known source of bugs that are hard to track, that's why DUP=FALSE is flagged as dangerous in bold face).

Cheers,
Simon