I gave this a whirl and I'm very pleased with the result.

I have tried my test on 2.13.1 (code below) using rgeos_0.1-9 (+
stringr_0.5 sp_0.9-88). I ran the below code a number of times and memory
kept climbing. Closing that R session released the memory.

I did exactly the same step using 2.14.1 with rgeos_0.2-1 (+ stringr_0.6
sp_0.9-93) and I didn't notice a significant climb in memory usage. If
there is any, it's negligible on my workstation.

I have visualized this on the following picture:
http://dl.dropbox.com/u/8161901/memoryleakdiag.jpg
Caption: 2.14.1 uses rgeos_0.2-1 and 2.13.1 uses rgeos_0.1-9


Cheers,
Roman



library(rgeos)
origin.point <- SpatialPoints(matrix(c(0, 0), ncol = 2))
circles.along <- seq(from = 0, to = 10, by = 0.01)[-1]
circles <- sapply(X = circles.along, FUN = function(x, origin =
origin.point) {
            gBuffer(spgeom = origin, width = x, quadsegs = 30)
        })
polygon.list <- vector("list", length(circles.along))
for (i in 1:length(circles.along)) {
    # inner-most ring should not be clipped
    if (i == 1) {
        polygon.list[[i]] <- circles[[i]]
    } else {
        polygon.list[[i]] <- gDifference(spgeom1 = circles[[i]], spgeom2 =
circles[[i-1]])
    }
}
rm(polygon.list)
rm(circles)
gc()







On Tue, Jan 17, 2012 at 4:18 PM, pgalpern <pgalpern@gmail.com> wrote:

> Roger,
>  Thanks to all for efforts to improve this very useful package.
>
>  I am going to cautiously suggest that the memory leak with
> raster::rasterToPolygons(x, dissolve=TRUE) which calls rgeos::gUnaryUnion()
> is  fixed -- or has improved considerably.
>
> Previously,  running this function on a raster of 800 000 cells (which, as
> you pointed out in another thread, is at the best of times a memory
> intensive task) quickly consumed all the available overhead memory and
> headed into disk swapping.  Now, I can run the same raster and memory is
> consumed up to what appears to be the R gc() trigger point, and then
> stabilizes (suggesting that R can now release the memory, which it
> previously could not).  I should note, however, that 7 GB was freed only
> after the R instance was closed.  Calls to gc() did not release this.  This
> may be expected behaviour, not sure.
>
> (Run under 64bit R 2.14.1).
>
> Thanks!
> Paul
>
> --
> Paul Galpern, PhD Candidate
> Natural Resources Institute
> 70 Dysart Road
> University of Manitoba
> Winnipeg, Manitoba, Canada R3T 2M6
> http://borealscape.ca
>
>
>
>  Date: Mon, 16 Jan 2012 14:26:34 +0100 (CET)
>> From: Roger Bivand<Roger.Bivand@nhh.no>
>> To:r-sig-geo@r-project.org
>>
>> Subject: [R-sig-Geo] rgeos 0.2-1 released
>> Message-ID:<alpine.LRH.2.02.**1201161400310.21470@reclus.**nhh.no<alpine.LRH.2.02.1201161400310.21470@reclus.nhh.no>
>> >
>> Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
>>
>>
>> Edzer Pebesma and Colin Rundel have made progress with finding and
>> removing memory leaks on rgeos, so we've released 0.2-1. It would be
>> useful to receive reports on changes in usability. The OSX binary for
>> 0.2-1 is already on CRAN Extras, the Windows binary is diffusing across
>> CRAN mirrors.
>>
>> Roger
>>
>
> ______________________________**_________________
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/**listinfo/r-sig-geo<https://stat.ethz.ch/mailman/listinfo/r-sig-geo>
>



-- 
In God we trust, all others bring data.

	[[alternative HTML version deleted]]

