From lgautier at gmail.com  Sat Jan  2 18:17:01 2010
From: lgautier at gmail.com (Laurent Gautier)
Date: Sat, 02 Jan 2010 18:17:01 +0100
Subject: [Rd] R-devel Digest, Vol 83, Issue 2
In-Reply-To: <4B3F7ACD.2050106@stats.uwo.ca>
References: <mailman.11.1262430004.8711.r-devel@r-project.org>
	<4B3F7625.1080806@gmail.com> <4B3F7ACD.2050106@stats.uwo.ca>
Message-ID: <4B3F7F8D.8060701@gmail.com>

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).



L.


> 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
>



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