[geos-devel] JTS/GEOS performance

[strk at refractions.net]

Thanks to Norman Vine I've handled to run gprof.
I found a couple of probaly useless copying.

One is SegmentString taking ownership of passed-in CoordinateSequence
and deleting it a destruction time.

To avoid segfaults it returns a cloned version with getCoordinates()
while I added getCoordinatesRO() for callers that don't need
a copy. It should avoid deleting and cloning. 
Lifespan of newly constructed coordinates should be tracked more
carefully though, as buffer ops constructs circles and then trims
them down, so deletion of unused coordinates will be needed while
the coordinates used in the output should be kept. Much easier
with Java GC... A smart_pointer might be useful there.

Another one is Edge, doing the same thing (taking ownership and
deleting the passed-in sequence).

I'll do some more tests to see how this can be handled.

--strk;

On Wed, Feb 02, 2005 at 07:27:09PM +0100, strk at refractions.net wrote:
> On Wed, Feb 02, 2005 at 10:05:31AM -0800, Martin Davis wrote:
> > > That's a virtual call, so cannot be statically bound.
> > > A simple coordlist[4] on the other hand is usually inlined. 
> > > (C++ gurus correct me if I'm wrong)
> > 
> > Good point.  But surely this alone can't account for the difference
> > between GEOS and JTS?  I doubt Java is doing much "inlining" either.
> 
> I have a precise answer, after spending the whole day on it.
> It doesn't help much. Buffer(2000) runs in 59secs vs. 60secs
> of using CoordinateSequence :(
> 
> > > Geometry#getCoordinates() returns Coordinate[], not
> > CoordinateSequence. 
> > 
> > I know, that's my point.  The JTS codebase should be using
> > getCoordinateSequence almost exclusively.
> > 
> > > assumption of a "fast" implementation has always been in JTS, 
> > > see the toInternalCoordinate() method.
> > 
> > Yes, but I'm trying to move JTS away from assuming this.
> > 
> > > Nope. GEOS actually dropped CoordinateArrays and 
> > > CoordinateList classes merging all into CoordinateSequence. 
> > 
> > That's unfortunate - these 3 classes have very different uses.
> 
> I guess they will need a change anyway in next JTS, as they
> work on Coordinate[], not CoordinateSequence.
> 
> > > Note that for DefaultCoordinateSequence, 
> > > the #toVector() method doesn't involve any copy.
> > 
> > Well that removes one possible source of unecessary memory allocation.
> > Can you think of anywhere else where memory allocation might be
> > happening that could be removed?
> 
> Well.. all over the codebase.. not easy to tell.
> For sure we have a ::removeRepeatedPoints which always returns
> a copy while for JTS only copies when needed, but again I don't 
> think it's enough to make that difference.
> 
> I think it'll be usefull to have JTS give some debugging/profiling
> info to compare operations (allocations, copies...)
> 
> --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