[postgis-devel] Another Data Point

Wed Jan 21 11:43:59 PST 2009

Paul,
I wouldn't proclaim victory on that alone.  

Do another test.  20 seconds sounds a little too short.  
I'm not saying it isn't right and my memory may be wrong on the JTS result too.
Besides JTS would have to collect geometries as well I imagine so you can't simply throw that out and proclaim victory.

Test out

SELECT geometrytype(st_unite_garray(ARRAY(SELECT the_geom FROM sample_poly)))

Though that wouldn't be quite a true test either. But somewhere between the
two would be the answer.

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul Ramsey
Sent: Wed 1/21/2009 1:58 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Another Data Point

Well, just running this:

uniontest=# select geometrytype(collect(the_geom)) from sample_poly;
  geometrytype
--------------------
 GEOMETRYCOLLECTION
(1 row)

Time: 261624.195 ms

takes 251 of the 271 seconds the union operation took... the
implication is that the GEOS portion of the work is on the order of 10
seconds.

P.

On Wed, Jan 21, 2009 at 10:10 AM, Martin Davis <mbdavis at refractions.net> wrote:
> Could be...   It would be interesting to see whether GEOS is faster than
> JTS.   Needs a test environment able to run both pieces of code on the same
> hardware.
>
> Paul Ramsey wrote:
>>
>> 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
>>
>>
>
> --
> 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

-----------------------------------------
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20090121/0e9beab5/attachment.html>