Okay thanks, I'm going through the docs now.. and I came through this.. The named field is set and accessed by the SET_NAMED and NAMED macros, and take values 0, 1 and 2. R has a `call by value' illusion, so an assignment like b <- a appears to make a copy of a and refer to it as b. However, if neither a nor b are subsequently altered there is no need to copy. What really happens is that a new symbol b is bound to the same value as a and the named field on the value object is set (in this case to 2). When an object is about to be altered, the named field is consulted. A value of 2 means that the object must be duplicated before being changed.
What does it mean "the new symbol b is bound to the same value as a". Does it mean b has a pointer pointing to a? Thanks!! - yooooooooooo yoooooo wrote: > > I guess I have more reading to do.... Are there any website that I can > read up on memory management, or specifically what happen when we 'pass > in' variables, which strategy is better at which situation? > > Thanks~ > - yoooooooo > > > Prof Brian Ripley wrote: >> >> On Tue, 10 Apr 2007, yoooooo wrote: >> >>> >>> Hi all, I'm just curious how memory management works in R... I need to >>> run an >>> optimization that keeps calling the same function with a large set of >>> parameters... so then I start to wonder if it's better if I attach the >>> variables first vs passing them in (coz that involves a lot of copying.. >>> ) >> >> Your paranethetical comment is wrong: no copying is needed to 'pass in' a >> variable. >> >>> Thus, I do this >>> fn3 <- function(x, y, z, a, b, c){ sum(x, y, z, a, b, c) } >>> fn4 <- function(){ sum(x, y, z, a, b, c) } >>> >>> rdn <- rep(1.1, times=1e8) >>> r <- proc.time() >>> for (i in 1:5) >>> fn3(rdn, rdn, rdn, rdn, rdn, rdn) >>> time1 <- proc.time() - r >>> print(time1) >>> >>> lt <- list(x = rdn, y = rdn, z = rdn, a = rdn, b = rdn, c = rdn) >>> attach(lt) >>> r <- proc.time() >>> for (i in 1:5) >>> fn4() >>> time2 <- proc.time() - r >>> print(time2) >>> detach("lt") >>> >>> The output is >>> [1] 25.691 0.003 25.735 0.000 0.000 >>> [1] 25.822 0.005 25.860 0.000 0.000 >>> >>> Turns out attaching takes longer to run.. which is counter intuitive >>> (unless >>> the search to the pos=2 envir takes long time as well) Do you guys know >>> why >>> this is the case? >> >> I would not trust timing differences of that nature: they often depend on >> the state of the system, and in particular of the garbage collector. >> You should be using system.time() for that reason: it calls the garbage >> collector immediately before timing. >> >> -- >> Brian D. Ripley, [EMAIL PROTECTED] >> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ >> University of Oxford, Tel: +44 1865 272861 (self) >> 1 South Parks Road, +44 1865 272866 (PA) >> Oxford OX1 3TG, UK Fax: +44 1865 272595 >> >> ______________________________________________ >> [EMAIL PROTECTED] mailing list >> https://stat.ethz.ch/mailman/listinfo/r-help >> PLEASE do read the posting guide >> http://www.R-project.org/posting-guide.html >> and provide commented, minimal, self-contained, reproducible code. >> >> > > -- View this message in context: http://www.nabble.com/Memory-management-tf3556238.html#a9961010 Sent from the R help mailing list archive at Nabble.com. ______________________________________________ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.