[geos-devel] JTS/GEOS performance

[strk at refractions.net]

An example for the Edge case:

Edge::getCollapsedEdge()

allocates a new DefaultCoordinateSequence, pass it to a new Edge
and returns the Edge.

The newly created DefaultCoordinateSequence will leak. How can this
be avoided ?

How long must the Sequence last in memory ?
Who should delete it ?
Can we think about having a possibly-owning possibly-notowning
Edge instance ? Should we use smart_ptr ?

--strk;

On Thu, Feb 03, 2005 at 12:29:32PM +0100, strk at refractions.net wrote:
> 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
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel