[R] Memory management

[yoooooo]

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,                  ripley at stats.ox.ac.uk
>> 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
>> 
>> ______________________________________________
>> R-help at stat.math.ethz.ch 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.