[geos-devel] Benchmark between various geometry libraries

[Hartmut Kaiser]

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

a) It is known that the abstraction penalty to be paid for using vectors
over plain arrays if properly used is in the range of 1-2% (see here:
http://tinyurl.com/yhca3kd, look for 'release build with _SECURE_SCL
disabled' to see the evidence, others have verified those results using
other compilers). It's hardly worth removing the use of vectors to gain 1-2%
in performance if the difference in performance between GEOS and GGL is in
the order of magnitudes. Even more as GGL uses vectors extensively as well. 

b) allocation cost for plain arrays would not be smaller than if using
vectors properly

c) exception safety would be much more difficult to achieve if compared to
properly used vectors.

d) passing vectors by value (or returning those from functions) is certainly
a performance killer, indeed, this should be changed to passing by
const&/non-const&.

Regards Hartmut

-------------------
Meet me at BoostCon
http://boostcon.com

> 
> 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
> 
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel