R, deep vs. shallow copies, pass by reference

Question

I would like to understand the logic R uses when passing arguments to functions, creating copies of variables, etc. with respect to the memory usage. When does it actually create a copy of the variable vs. just passing a reference to that variable? In particular the situations I am curious about are:

f <- function(x) {x+1}
a <- 1
f(a)

Is a being passed literally or is a reference to a being passed?

x <- 1
y <- x

Reference of copy? When is this not the case?

If someone could explain this to me I would highly appreciate.

You might find [this](http://cran.at.r-project.org/doc/manuals/R-lang.html#Evaluation) section of the R language definition helpful. — joran, May 18 '12 at 15:25
This paper by Morandat and colleagues has an interesting and critical discussion of lazy evaluation of arguments in R: http://www.cs.purdue.edu/homes/jv/pubs/ecoop12.pdf — jthetzel, May 18 '12 at 15:43
Using `tracemem` on an appropriately compiled R can be helpful for exploration, as can `.Internal(inspect(x))` with an understanding of the `NAM`ED field; my general mantra is 'copy-on-change' so for instance your `y <- x` does not trigger a copy (yet) because there has been no change to the original, the memory pointed to by `x` (and `y`) is `NAMED` such that modification of either will trigger a copy. — Martin Morgan, May 18 '12 at 16:32

score 19 · Accepted Answer · edited May 23 '17 at 11:33

When it passes variables, it is always by copy rather than by reference. Sometimes, however, you will not get a copy made until an assignment actually occurs. The real description of the process is pass-by-promise. Take a look at the documentation

?force
?delayedAssign

One practical implication is that it is very difficult if not impossible to avoid needing at least twice as much RAM as your objects nominally occupy. Modifying a large object will generally require making a temporary copy.

update: 2015: I do (and did) agree with Matt Dowle that his data.table package provides an alternate route to assignment that avoids the copy-duplication problem. If that was the update requested, then I didn't understand it at the time the suggestion was made.

There was a recent change in R 3.2.1 in the evaluation rules for apply and Reduce. It was SO-announced with reference to the News here: Returning anonymous functions from lapply - what is going wrong?

And the interesting paper cited by jhetzel in the comments is now here:

Enter [`data.table`](http://datatable.r-forge.r-project.org/). See `?copy` in the package. Assignment by reference is possible with the `:=` operator, see `?":="` and the series of `set*` functions. Instead of needing room for 2-3 copies of the entire object, we aim to only need one column's worth of working memory or less. — Matt Dowle, May 21 '12 at 15:32

score 13 · Answer 2 · answered Oct 15 '19 at 10:29

Late answer but a very important aspect of the language design that don't get enough coverage on the web (or at least the usual sources).

x <- c(0,4,2)
lobstr::obj_addr(x)
# [1] "0x7ff25e82b0f8"
y <- x
lobstr::obj_addr(y)
# [1] "0x7ff25e82b0f8"

Notice the identical "memory address", i.e. the location in memory where the object is stored. You can thus confirm that x and y both point to the same identifier.

Hadley Wickham's Advanced R book touch on this:

Consider this code:

x <- c(1, 2, 3)

It’s easy to read it as: “create an object named ‘x’, containing the values 1, 2, and 3”. Unfortunately, that’s a simplification that will lead to inaccurate predictions about what R is actually doing behind the scenes. It’s more accurate to say that this code is doing two things:

It’s creating an object, a vector of values, c(1, 2, 3). And it’s binding that object to a name, x. In other words, the object, or value, doesn’t have a name; it’s actually the name that has a value.

Note that they are the memory addresses are ephemeral and change with every new R session.

Now here is the important part.

In R semantics, objects are copied by value. This means that modifying the copy leaves the original object intact. Since copying data in memory is an expensive operation, copies in R are as lazy as possible. They only happen when the new object is actually modified. Source: [R lang documentation][1]

So if we now modify the value of y by appending a value to the vector, y now points to a different "object". This agrees with what the documentation says regarding a copy operation happening "only when the new object is modified" (lazy). y is pointing to a different address than it was previously.

y <- c(y, -3)
print(lobstr::obj_addr(y))
# [1] "0x7ff25e825b48"

tim · Answer 3 · 2020-03-31T04:40:05.543

@onlyphantom That's super helpful! And objects can round trip out of a function without being copied also: which was what brought me here:

tmp <- function(x, create) {
    if(!create){
        x
    }else{
        "new"
    }
}

x = c(0,4,2)

y = tmp(x, F)
lobstr::obj_addr(x) == lobstr::obj_addr(y) # y points to x!

And this works when "replacing" x with itself - no copy!

oldAddr = lobstr::obj_addr(x) 
x = tmp(x, F)
lobstr::obj_addr(x) == oldAddr # TRUE!

This example from the manual (modified slightly) was also informative about triggering a lazy evaluation

tmp = function(x, label = deparse(x), force=TRUE) {
    if(force){
        label
    }
    x <- x + 1
    print(label); return(x)
}
tmp(2)
[1] "2"
[1] 3

tmp(2, force=F)
[1] "3"
[1] 3

R version 3.6.3

Thank you for the insightful examples! Do you know if this copying of an object – say a matrix – also happen when we are using subsets of the object as arguments to a function? — pglpm, Oct 22 '22 at 12:21

R, deep vs. shallow copies, pass by reference

3 Answers3

Linked