[geos-devel] [GEOS] #343: After applying a buffer over a multiline the library starts growing in memory usage and hungs

[Martin Davis]

Ok, then that's in the same ballpark as JTS.  And yes, the union is much 
slower than the buffer creation.

Interesting that GEOS seems to have caught up to JTS in terms of 
performance.  I seem to remember it used to be slower.  (But it's not 
really any faster, either, in spite of all that C goodness!  8^)

strk wrote:
> On Fri, May 14, 2010 at 11:35:45AM -0700, Martin Davis wrote:
>   
>> Ok, I tried the roads_broken geometry in JTS using the buffer-and-union 
>> approach.  The result matches the one you posted, strk.
>>
>> Time was 2.7 s.  So the two systems are pretty close.
>>
>> It would be interesting if you tried the other geometry as well.
>>     
>
> Done, but on another (older) machine:
>  Intel(R) Pentium(R) 4 CPU 2.66GHz
>  bogomips        : 5333.43
>
> Input points: 11502
> Input components: 5615
> Output points: 417
>
> $ time psql -c ' select st_npoints(st_union(st_buffer(geom, 0.005)))
> from ( select (st_dump(g)).geom from bug ) as foo; '
>  real    1m9.838s
>  user    0m0.100s
>  sys     0m0.028s
>
> Memory is fine, CPU is pretty much fixed at 100%.
>
> Interesting enough the buffer itself is pretty quick:
>
> $ time psql -c ' select sum(st_npoints(st_buffer(geom, 0.005)))
> from ( select (st_dump(g)).geom from bug ) as foo;'
>  real    0m3.170s
>  user    0m0.108s
>  sys     0m0.024s
>
> --strk;
>
>   ()   Free GIS & Flash consultant/developer
>   /\   http://strk.keybit.net/services.html
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022