[geos-devel] JTS/GEOS performance

[strk at refractions.net]

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.

--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