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 cost
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 declare
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 (
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 op
strk wrote:
> Well, a lot of these are likely unused places after all so I stop here :)
What might be interesting is to grep files that might contain
performance sensitive code in the list rather than iterating on all the
results.
> I think the correct way to proceed if we want to make GEOS any f
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 i
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 65
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
On Thu, Nov 19, 2009 at 02:36:30PM -0700, Martin Chapman wrote:
> For my own knowledge, did you see a decent performance gain when you made
> the change or was it only a small increase in speed?
Generally speaking, the biggest performance gains I've ever seen
in GEOS had origin in algorithmical ch
, 2009 2:34 PM
To: GEOS Development List
Subject: Re: [geos-devel] Benchmark between various geometry libraries
On Thu, Nov 19, 2009 at 10:14:17AM -0700, Martin Chapman wrote:
> Also, I noticed a long time ago that GEOS passes these vectors around to
> functions by value versus by reference.
On Thu, Nov 19, 2009 at 10:14:17AM -0700, Martin Chapman wrote:
> 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
On Thu, Nov 19, 2009 at 05:16:53PM +0100, Maxime van Noppen wrote:
> > ~/dev/geos/trunk $ grep 'new std' `find . -iname '*.cpp'`
Thanks for another couple of eyes (see below for comment/fixes).
> > ./capi/geos_ts_c.cpp:std::vector* vgeoms = new
> > std::vector(geoms, geoms + ngeoms);
[.
> [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:
>
artin
-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
7;
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 pixe
Hi,
I don't want to mingle in this discussion but on this point:
However given the geos implementation :
https://svn.boost.org/svn/boost/sandbox/ggl/other/comparison_star_comb/geos/geos_starcomb.cpp
It shouldn't be hard to write a similar JTS test. I never developed in
Java though, so I am
strk wrote:
> 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.
Indeed there are not that
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 alloc
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
pre
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 shou
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 the
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 the
thread-safety improvements have, I think, removed the last little
leaky bit I could stuff inside
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 w
> 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.
It's not that allocation is nec
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 shou
> 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 templati
Paul Ramsey wrote:
> I wonder if we could somehow prevail upon Maxime to add JTS to the
> benchmark set, to disentangle algorithm from implementation.
I have nothing to do with GGL. But as both geos & boost user I follow
both lists and as I'm interested in geometry related libraries I tried
out GG
Yeah, that'd be interesting. I thought about trying to run the test
cases, but it's not really relevant unles they are run in the same
environment.
Paul Ramsey wrote:
I wonder if we could somehow prevail upon Maxime to add JTS to the
benchmark set, to disentangle algorithm from implementation
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, VS
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 wrote:
> Probably something as simple as running Maxime's test polygons and
> watching the profile in Shark would give t
Probably something as simple as running Maxime's test polygons and
watching the profile in Shark would give the answer, since the
difference is so huge.
P.
On Wed, Nov 18, 2009 at 9:39 AM, Martin Davis wrote:
>
>
> Maxime van Noppen wrote:
>>
>> It's quite interesting to have some numbers though
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 co
Martin Davis wrote:
> I'm not sure that anything "went wrong" with the tests. The results may
> be due to fundamental design differences between GGL and GEOS. These
> include:
>
> - GEOS uses a less efficient memory handling strategy, primarily due to
> the goal of tracking JTS closely (and also
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 faster
I'm not sure that anything "went wrong" with the tests. The results may
be due to fundamental design differences between GGL and GEOS. These
include:
- GEOS uses a less efficient memory handling strategy, primarily due to
the goal of tracking JTS closely (and also due to the substantial
bra
Hi list,
A geometry library is currently being reviewed by the Boost project (GGL
- Generic Geometry Library)[1] and they did some benchmarks available here:
http://trac.osgeo.org/ggl/wiki/IntersectionMore
http://trac.osgeo.org/ggl/wiki/IntersectionStarComb
Depending on the situations geos perfo
36 matches
Mail list logo
