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
#287: Shouldn't GEOS 3.1 branch be bumped to 3.1.2
+---
Reporter: robe|Owner: geos-devel@lists.osgeo.org
Type: defect | Status: closed
Priority: trivial |Milest
#287: Shouldn't GEOS 3.1 branch be bumped to 3.1.2
+---
Reporter: robe|Owner: geos-devel@lists.osgeo.org
Type: defect | Status: closed
Priority: trivial |Milest
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
19 matches
Mail list logo
