One typo on last email: COOORD** coords = new*[numCoordinates];
Should have been: COOORD** coords = new COOORD*[numCoordinates]; Martin -----Original Message----- From: Martin Chapman [mailto:chapm...@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-boun...@lists.osgeo.org [mailto:geos-devel-boun...@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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel _______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel