[geos-devel] JTS/GEOS performance

[strk at refractions.net]

On Tue, Feb 01, 2005 at 11:25:05PM +0100, strk at refractions.net wrote:
> On Tue, Feb 01, 2005 at 11:22:54PM +0100, strk at refractions.net wrote:
> > On Tue, Feb 01, 2005 at 10:52:23AM -0800, Martin Davis wrote:
> > > Well it's good to hear that GEOS isn't wildly different to JTS timings
> > > after all.
> > 
> > Yeah, but it's still 3.5 times slower ...
> > 
> > > After some more thought I think there may be some improvements which
> > > don't require implementing smart ptrs and ref counting (not that these
> > > are bad things to do, they just take time).
> > >  
> > > I suspect that heavy use is being made of
> > > CoordinateSequence::getCoordinate, and that this is resulting in many
> > > Coordinate objects being allocated.  A better pattern for callers is to
> > > preallocate a single Coordinate and then use getCoordinate(Coordinate *)
> > > to retrieve coordinate values into it.  (JTS doesn't do this now, but
> > > will be moving to this style to reduce *its* allocation of Coordinate
> > > objects).
> > 
> > GEOS use CoordinateSequence::getAt, which returns a *reference*, so
> > no allocation is involved. Explicit copy is performed if the caller
> > assigns the return to a real Coordinate (as opposite to a Coordinate
> > ref).
> > 
> > Taking a closer look of our bottleneck
> > (indexMonotoneChain::computeOverlaps) I found out that GEOS
> > uses CoordinateSequence where JTS uses Coordinate[].
> > This means one level of indirection less.
> > GEOS getAt internally calls the equivalent of JTS [] operator,
> > calling it directly should give us some better results.
> > 
> > Probably inlining CoordinateSequence::getAt() would give same
> > results w/ less effort but breaking ABI. I'll check this.
> 
> Oops.. I correct myself, we cannot inline CoordinateSequence::getAt()
> as it's a virtual class. Still I'd consider using vector<Coordinate>,
> which can returned with no copy involved by the DefaultCoordinateSequence
> using the toVector() method.

Using a vector in indexMonotoneChain takes timing down from 63 to 60
seconds.

I've verified that none of the JTS code in index/, in noding/,
in algorithm/ and in geomgraph/ use CoordinateSequence, while
GEOS does it everywhere.

My proposal is to make GEOS interfaces closer to JTS in using vectors
of Coordinates wherever JTS uses Coordinate[]. 

In order to maintain current API we should add new interfaces
instead of replacing old ones. ABI would still break, but this
seems inevitable so far.

Comments ?

--strk;


> 
> --strk;
> 
> > 
> > --strk;
> > 
> > > Martin Davis, Senior Technical Architect
> > > Vivid Solutions Inc.      www.vividsolutions.com
> > > Suite #1A-2328 Government Street Victoria, B.C. V8T 5G5
> > > Phone: (250) 385 6040 - Local 308 Fax: (250) 385 6046
> > >  
> > 
> > > _______________________________________________
> > > geos-devel mailing list
> > > geos-devel at geos.refractions.net
> > > http://geos.refractions.net/mailman/listinfo/geos-devel
> > 
> > _______________________________________________
> > geos-devel mailing list
> > geos-devel at geos.refractions.net
> > http://geos.refractions.net/mailman/listinfo/geos-devel
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel