[Rd] R-devel Digest, Vol 83, Issue 2

Laurent Gautier lgautier at gmail.com
Sat Jan 2 18:17:01 CET 2010

On 1/2/10 5:56 PM, Duncan Murdoch wrote:
> On 02/01/2010 11:36 AM, Laurent Gautier wrote:
>> [Disclaimer: what is below reflects my understanding from reading the
>> R source, others will correct where deemed necessary]
>> On 1/2/10 12:00 PM, r-devel-request at r-project.org wrote:


>>> I'd also be interested if there is some ideas on the relative efficiency
>>> of the preserve/release mechanism compared to PROTECT/UNPROTECT.
>> PROTECT/UNPROTECT is trading granularity for speed. It is a stack with
>> only tow operations possible:
>> - push 1 object into the stack
>> - pull (unprotect) N last objects from the stack
> UNPROTECT_PTR is also possible, which does a linear search through the
> stack and unprotects something possibly deep within it. There is also
> REPROTECT which allows you to replace an entry within the stack.
> I would guess that UNPROTECT_PTR is more efficient than RecursiveRelease
> because it doesn't use so much stack space when it needs to go deep into
> the stack to release, but it is possible the compiler recognizes the
> tail recursion and RecursiveRelease is implemented efficiently. In that
> case it could be more efficient than UNPROTECT_PTR, which has to move
> all the other entries down to fill the newly vacated space. Really the
> only reliable way to answer efficiency questions like this is to try
> both ways and see which works better in your application.

Thanks. I did not know about UNPROTECT_PTR.
I had concerns over the stack usage, but so far it did not prove too 
much of a problem. Still, why isn't the tail recursion explicitly made 
an iteration then ? This would take the "may be the compiler figures it 
out, may be not" variable out of the equation.

> Another possibility is to maintain your own list or environment of
> objects, and just protect/preserve the list as a whole.

Interesting idea, this would let one perform his/her own bookkeeping on 
the list/environment. How is R garbage collection checking contained 
objects ? (I am thinking performances here, and may be cyclic references).


> Duncan Murdoch
>> HTH,
>> L.
>>> Thanks,
>>> Romain
>>> [1]http://lists.r-forge.r-project.org/pipermail/rcpp-devel/
>>> [2]
>>> http://r-forge.r-project.org/plugins/scmsvn/viewcvs.php/pkg/src/RObject.cpp?rev=255&root=rcpp&view=markup
>>> -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30
>>> http://romainfrancois.blog.free.fr |- http://tr.im/IW9B : C++ exceptions
>>> at the R level |- http://tr.im/IlMh : CPP package: exposing C++ objects
>>> `- http://tr.im/HlX9 : new package : bibtex
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel

More information about the R-devel mailing list