[postgis-devel] Another Data Point

[Obe, Regina]

You can try using st_unite_cascade_garray instead of ST_Union aggregate.

I think that would be a closer test to raw GEOSUnionCascaded.  Although
you probably have an easier way of testing this. 

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Paul
Ramsey
Sent: Wednesday, January 21, 2009 12:14 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Another Data Point

I got another run in, right near the end, and it showed that
GEOSUnionCascaded took only about 50% of the time in that slice. There
was still more memcpy'ing first. I bet GEOSUnionCascaded on its own
would be as fast as JTS (or faster?).

P.

On Wed, Jan 21, 2009 at 9:05 AM, Paul Ramsey <pramsey at cleverelephant.ca>
wrote:
> Interesting! The Shark only samples for about 20 seconds, so I only
> got the first 10% or so of the run, and the biggest user in that time
> period memcpy'ing in LWGEOM_accum (postgis) and
> advance_transition_function (pgsql). So we are spending a non-trivial
> amount of time just accumulating the input...
>
> P
>
> On Wed, Jan 21, 2009 at 9:00 AM, Paul Ramsey
<pramsey at cleverelephant.ca> wrote:
>> The glove is dropped indeed... why speculate when I have the Shark...
>> time to see where our time goes...
>>
>> P
>>
>> On Wed, Jan 21, 2009 at 8:55 AM, Martin Davis
<mbdavis at refractions.net> wrote:
>>> Go for it, Regina!  The glove is dropped...
>>>
>>> Although I suspect this test may simply be running into the slower
memory
>>> performance due to any or all of Postgres, C, GEOS compared to good
ol'
>>> Java...  Hard to beat that tuned JVM memory manager!
>>>
>>> Obe, Regina wrote:
>>>>
>>>> Ah I think JTS was able to do this in about 40-50 seconds.  And my
>>>> version was able to beat out Kevin's nested by a small margin.
I'll
>>>> retest on mine.
>>>>
>>>> So I think we still need work here.
>>>>
>>>> I'm curious what would happen if I combined the algorithm I wrote
with
>>>> the new ST_Union how things would fair.  In theory it should fair
the
>>>> same, but I'm not really using Martin's cascaded union algorithm to
the
>>>> letter.
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: postgis-devel-bounces at postgis.refractions.net
>>>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
Paul
>>>> Ramsey
>>>> Sent: Wednesday, January 21, 2009 12:50 AM
>>>> To: PostGIS Development Discussion
>>>> Cc: lee.keel at uai.com
>>>> Subject: [postgis-devel] Another Data Point
>>>>
>>>> Using the original sample set from Lee Keel,
>>>>
>>>> With the old style ST_Union, 3 hours, 27 minutes:
>>>>
>>>> uniontest=# select st_area(st_union(the_geom)) from sample_poly;
>>>>      st_area
>>>> --------------------
>>>>  0.0324039850011104
>>>> (1 row)
>>>>
>>>> Time: 12419261.819 ms
>>>>
>>>>
>>>> With the new cascaded ST_Union, 4 minutes, 30 seconds, or 46 times
>>>> faster.
>>>>
>>>> uniontest=# select st_area(st_union_fast(the_geom)) from
sample_poly;
>>>>      st_area
>>>> --------------------
>>>>  0.0324039850054305
>>>> (1 row)
>>>>
>>>> Time: 271618.181 ms
>>>>
>>>>
>>>> That's one nasty data set.
>>>>
>>>> P.
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel at postgis.refractions.net
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>> -----------------------------------------
>>>> The substance of this message, including any attachments, may be
>>>> confidential, legally privileged and/or exempt from disclosure
>>>> pursuant to Massachusetts law. It is intended
>>>> solely for the addressee. If you received this in error, please
>>>> contact the sender and delete the material from any computer.
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel at postgis.refractions.net
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>>
>>>>
>>>
>>> --
>>> Martin Davis
>>> Senior Technical Architect
>>> Refractions Research, Inc.
>>> (250) 383-3022
>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>>
>
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel