Maxime van Noppen wrote:
I will post any numbers I get.
I'm still far from having a solid and complete report but just to give
you a taste : on 100 intersections dynamic allocations represent 25.01%
of the time cost (17.14% spent allocating, 7.87% deallocating).
I've also found several small
On Wed, Dec 09, 2009 at 05:13:15PM +0100, Maxime van Noppen wrote:
Maxime van Noppen wrote:
I will post any numbers I get.
I'm still far from having a solid and complete report but just to give
you a taste : on 100 intersections dynamic allocations represent 25.01%
of the time cost (17.14%
strk wrote:
CoordinateArraySequence::getAt is a virtual function, which is probably
the reason why the fully templated solution is much faster instead.
How can a virtual method be inlined by the compiler ?
Obviously it can't. I just missed the fact it was virtual because it's
not declared
strk wrote:
On Wed, Dec 09, 2009 at 05:13:15PM +0100, Maxime van Noppen wrote:
Maxime van Noppen wrote:
I will post any numbers I get.
I'm still far from having a solid and complete report but just to give
you a taste : on 100 intersections dynamic allocations represent 25.01%
of the time
On Fri, Nov 20, 2009 at 06:42:53PM +0100, Maxime van Noppen wrote:
I looked for any 'new std::something' but I just found there are 'using
namespace std;' in the code, and therefore we should also look for 'new
something'. I found 120 'new vector' out of 656 'new something' :
Yeah, I knew it
strk wrote:
Thanks for another couple of eyes (see below for comment/fixes).
Great work !
--
Maxime
___
geos-devel mailing list
geos-devel@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geos-devel
strk wrote:
Thanks for another couple of eyes (see below for comment/fixes).
I've got some bad news. :-)
I looked for any 'new std::something' but I just found there are 'using
namespace std;' in the code, and therefore we should also look for 'new
something'. I found 120 'new vector' out of
Hartmut Kaiser wrote:
Well, as both allocators the one in JVM and the one used by the C++ compiler
is probably written in C or C++ I don't see why Java should be soo much
faster when it comes to allocating objects :-P
It's not that the allocator is faster but that the JVM has a pool of
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
: 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
I see that Matz has already been looking at a GGL binding for PostGIS,
and I think when the 2.0 cycle begins I will also examine the
possibility. Then we can see where the rubber meets the road. Even
where GGL has a strong base-case speed, thinks like PreparedGeometry
will probably make GEOS
Maxime van Noppen wrote:
It's quite interesting to have some numbers though, as sometimes they
can lead to significant performance boost (CascadedPolygonUnion is a
good example). It might be interesting to analyze why geos is 23x slower
than other geometry libraries in some cases whereas it
I wonder if we could somehow prevail upon Maxime to add JTS to the
benchmark set, to disentangle algorithm from implementation.
P.
On Wed, Nov 18, 2009 at 9:32 AM, Paul Ramsey pram...@cleverelephant.ca wrote:
Probably something as simple as running Maxime's test polygons and
watching the
Further to this, I did look at the GGL source to see if there were some
obvious algorithmic ideas that could be used in JTS/GEOS. But I got
lost in all the template code... 8^(
I am curious to know how much of the speed improvement is due to more
efficient compilation due to templating,
Hartmut Kaiser wrote:
It's not that allocation is necessarily slow
Well, compared to the JVM it is. Java is amazingly fast at allocating
objects.
Sharing is certainly a bit trickier this way, but allocating on the stack helps
defining proper ownership of the data.
For better or
It would be very interesting to see how this affects performance, for sure.
Paul Ramsey wrote:
I got within a hair of stuffing GEOS into the PgSQL palloc/pfree
memory pool last year, which would have dramatically reduced memory
allocation costs. I could probably make it work this year, since
Sorry sent to Martin only...
It's not that allocation is necessarily slow
Well, compared to the JVM it is. Java is amazingly fast at allocating
objects.
Well, as both allocators the one in JVM and the one used by the C++ compiler is
probably written in C or C++ I don't see why Java should
17 matches
Mail list logo
