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

[strk at refractions.net]

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