Though R usually adheres to copy-on-change semantics, there are excep-
tions. For example, R doesn’t exhibit the location-change behavior in the
following setting:
z <- runif(10)
tracemem(z)
[1] "<0x88c3258>"
z[3] <- 8
tracemem(z)
[1] "<0x88c3258>"
The location ofzdidn’t change; it was at memory address 0x88c3258
both before and after the assignment toz[3]was executed. Thus, although
you should be vigilant about location change, you also can’t assume it.
Let’s look at the times involved.
z <- 1:10000000
system.time(z[3] <- 8)
user system elapsed
0.180 0.084 0.265
system.time(z[33] <- 88)
user system elapsed
000
In any event, if copying is done, the vehicle is R’s internal function
duplicate(). (The function is calledduplicate1()in recent versions of R.)
If you’re familiar with the GDB debugging tool and your R build includes
debugging information, you can explore the circumstances under which a
copy is performed.
Following the guide in Section 15.1.4, start up R with GDB, step through
R through GDB, and place a breakpoint atduplicate1(). Each time you break
at that function, submit this GDB command:
call Rf_PrintValue(s)
This will print the value ofs(or whatever variable is of interest).14.3.3 Extended Example: Avoiding Memory Copy......................
This example, though artificial, will demonstrate the memory-copy issues
discussed in the previous section.
Suppose we have a large number of unrelated vectors and, among other
things, we wish to set the third element of each to 8. We could store the vec-
tors in a matrix, one vector per row. But since they are unrelated, maybe
even of different lengths, we may consider storing them in a list.
Performance Enhancement: Speed and Memory 315