R's copying of arguments (Re: Julia)
On Tue, Mar 20, 2012 at 12:08:12PM -0700, Herv? Pag?s wrote:
[...]
So the situation is somewhere between: "it is possible" and "R does not support a safe decision if, what is possible, also can be recommended". At the moment R rather deprecates in-place modification by default (the save way, and I agree with this default). But it's not true, that R in general copies arguments. But this seems to be true for the .C interface. Maybe a lot of performance-/memory-problems can be solved by rewriting already existing packages, by providing them via .Call instead of .C.
My understanding is that most packages use the .C interface because it's simpler to deal with and because they don't need to pass complicated objects at the C level, just atomic vectors. My guess is that it's probably rarely the case that the cost of copying the arguments passed to .C is significant, but, if that was the case, then they could always call .C() with DUP=FALSE. However, using DUP=FALSE is dangerous (see Warning section in the man page).
[...] Yes. I have seen that (DUP=FALSE) in the docs, but while I was writing the answer like a maniac, I forgot it. ;-) Thanks for mentionig it. In the manual also was mentioned, that .Call allows more control. I did not looked at .C and used .Call from the beginning on. It did not looked very complicated. But maybe .C would be much easier. Don't know.
No need to switch to .Call
OK, at least not for the point of DUP-arg. But it seems to me, that when later the names-result will be correctly set to 0, 1 and 2, then such optimisations, which were asked for, could be done "automagically". And to do it safely too. The .C interface with the DUP-arg seems not to allow this. Ciao, Oliver