FW: [geos-devel] Benchmark between various geometry libraries

[Martin Chapman]

One typo on last email:

COOORD** coords = new*[numCoordinates];

Should have been:

COOORD** coords = new COOORD*[numCoordinates];

Martin


-----Original Message-----
From: Martin Chapman [mailto:chapmanm at pixia.com] 
Sent: Thursday, November 19, 2009 10:14 AM
To: 'GEOS Development List'
Subject: RE: [geos-devel] Benchmark between various geometry libraries

Food for thought:

Stl vectors are not good for storing coordinates, pixel values, etc.  They
are extremely slow compared to an array of structs like:

COOORD** coords = new*[numCoordinates];

I used vectors for storing pixel values a long time ago and found that
looping through the values was super slow.  Then I created my own vector
class that used an internal array similar to the one above.  Performance was
awesome after the change.  I would suggest creating your own vector class
that resembled the stl vector and use that one instead.  Or, just use raw
arrays.  Allocation will be fast as well.

Also, I noticed a long time ago that GEOS passes these vectors around to
functions by value versus by reference.  That means the vector is getting
copied a lot.  I don't know if this has changed since then but that would be
a performance killer as well.

Just a thought...

Martin


-----Original Message-----
From: geos-devel-bounces at lists.osgeo.org
[mailto:geos-devel-bounces at lists.osgeo.org] On Behalf Of strk
Sent: Thursday, November 19, 2009 8:52 AM
To: GEOS Development List
Subject: Re: [geos-devel] Benchmark between various geometry libraries

On Wed, Nov 18, 2009 at 11:02:13AM -0800, Martin Davis wrote:
> Thanks for clarifying this, Hartmut.  This makes good sense to me.  In 
> my (admittedly limited and dated) experience, the C/C++ heap allocator 
> (good ol' malloc still, right?) is pretty slow.  From what you're saying 
> stack allocation is substantially faster.
> 
> The kind of change you indicated should be fairly simple to make in the 
> GEOS codebase.

I occasionally did rounds of such cleanups, but I think more time is spent
in copying read-only coordinates for the sake of memory management
while the JTS counterpart passes pointers around and delegates memory
management
to the garbage collector.

--strk;

 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple! 
_______________________________________________
geos-devel mailing list
geos-devel at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel