14.3 Functional Programming and Memory Issues..................................
Most R objects areimmutable, or unchangeable. Thus, R operations are
implemented as functions that reassign to the given object, a trait that can
have performance implications.
14.3.1 Vector Assignment Issues........................................
As an example of some of the issues that can arise, consider this simple-
looking statement:
z[3] <- 8
As noted in Chapter 7, this assignment is more complex than it seems. It
is actually implemented via the replacement function"[<-"through this call
and assignment:
z <- "[<-"(z,3,value=8)
An internal copy ofzis made, element 3 of the copy is changed to 8,
and then the resulting vector is reassigned toz. And recall that the latter
simply means thatzis pointed to the copy.
In other words, even though we are ostensibly changing just one ele-
ment of the vector, the semantics say thatthe entire vector is recomputed. For
a long vector, this would slow down the program considerably. The same
would be true for a shorter vector if it were assigned from within a loop of
our code.
In some situations, R does take some measures to mitigate this impact,
but it is a key point to consider when aiming for fast code. You should be
mindful of this when working with vectors (including arrays). If your code
seems to be running unexpectedly slowly, assignment of vectors should be a
prime area of suspicion.
14.3.2 Copy-on-Change Issues..........................................
A related issue is that R (usually) follows acopy-on-changepolicy. For instance,
if we execute the following in the previous setting:
>y<-z
then initiallyyshares the same memory area withz. But if either of
them changes, then a copy is made in a different area of memory, and the
changed variable will occupy the new area of memory. However, only the
firstchange is affected, as the relocating of the moved variable means there
are no longer any sharing issues. The functiontracemem()will report such
memory relocations.
314 Chapter 14