[geos-devel] Re: [postgis-users] JTS -- was Re: Transform Performance

[Robert Burgholzer]

Ahh. I selected GEOS at compile time, so no java blame there. I have
shifted this to the GEOS development forum, as I susptect it is more
appropriate there.

So, I wish to compare the intersection performance for the gpc library
with the current one in the GEOS library. However, it seems that the
geometry type has shifted to the LWG, is this the case? If so, I have
some fancy footwork to do, since I believe the gpc only wants to deal
with the older geometry type. Am I off base here?

Thanks,
Robert



On Thu, 2005-10-27 at 04:04, strk at refractions.net wrote:
> On Wed, Oct 26, 2005 at 05:46:42PM -0400, Robert Burgholzer wrote:
> > With regard to general performance, are the performance hits due to
> > execution of java functions?
> > 
> > I ask because, I think I found that the intersection() function seems to
> > be java based (in JTS). Is this a correct interpretation of what is
> > going on? I suppose I could just RTFLA (the friendly list archives that
> > is), as I recall the topics of porting java functions to postgis. I had
> > understood that this was the porting of java to C++, but perhaps that is
> > untrue. Anyone that can clarify this?
> 
> intersection() is a function performed by a separate library
> linked to the postgis library. At PostGIS compile time you 
> can choose this external library between:
> 	- GEOS built with a c++ compiler
> 	- EXPERIMENTAL JTS built with gcj (GNU Java compiler)
> 
> In this case no topological function is involved, so penalty is
> not due to these external libraries.
> 
> --strk;
> 
> > 
> > r.b.
> > 
> > 
> > On Wed, 2005-10-26 at 16:17, Charlie Savage wrote:
> > > Very interesting.  Following your lead I created this function and then 
> > > ran it through the scenarios you discuss below.
> > > 
> > > CREATE OR REPLACE FUNCTION
> > > testme(value int) RETURNS int
> > > AS $$
> > > BEGIN
> > > 	RAISE INFO 'testme: %', value;
> > > 	RETURN value;
> > > END;
> > > $$
> > > LANGUAGE plpgsql IMMUTABLE;
> > > 
> > > 
> > > I thought, but was wrong, that in this case the function would only be 
> > > called once:
> > > 
> > > select testme(MyField) from MyTable;
> > > 
> > > I had hoped that Postgresql would cache the value of the input 
> > > parameter, see that testme had already been invoked for that parameter, 
> > > and skip the evaluation.  However, it does not, the method get called 
> > > for every record.  From the Postgresql docs (emphasis is mine):
> > > 
> > > "An IMMUTABLE function cannot modify the database and is guaranteed to 
> > > return the same results given the same arguments forever. This category 
> > > allows the optimizer to pre-evaluate the function when a query calls it 
> > > with *constant* arguments."
> > > 
> > > > 
> > > > POSSIBLE OPTIMIZATIONS
> > > > 
> > > > First optimization that comes to mind is reducing scans by making
> > > > outer-level get_proj4_from_srid() calls take a constant argument:
> > > > 
> > > > 	transform_geometry(g, get_proj4_from_srid(find_srid(..)),
> > > > 		get_proj4_from_srid(4326));
> > > > 
> > > 
> > > Perhaps a quick simple way to do this is to create an overloaded version 
> > > of transform that takes both the source srs and targer srs as constants. 
> > >   That would get rid of all the SRID calls, and all but two of the 
> > > get_proj4_from_srid calls.  Thus it would be a lot faster, but not much 
> > > harder to use.
> > > 
> > > Thanks,
> > > 
> > > Charlie
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > postgis-users mailing list
> > > postgis-users at postgis.refractions.net
> > > http://postgis.refractions.net/mailman/listinfo/postgis-users
> > -- 
> > Non-point Source Data Analyst
> > University of Maryland, College Park
> > Chesapeake Bay Program Office
> > 410 Severn Avenue, Suite 305B
> > Annapolis, MD, 21403
> > Phone: (410) 267-5779
> > 
> > rburghol at chesapeakebay.net
> > 
> > _______________________________________________
> > postgis-users mailing list
> > postgis-users at postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-users
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
-- 
Non-point Source Data Analyst
University of Maryland, College Park
Chesapeake Bay Program Office
410 Severn Avenue, Suite 305B
Annapolis, MD, 21403
Phone: (410) 267-5779

rburghol at chesapeakebay.net