[geos-devel] Benchmark between various geometry libraries

[Hartmut Kaiser]

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 be soo much faster when it comes to allocating objects :-P

> > Sharing is certainly a bit trickier this way, but allocating on the
> stack helps defining proper ownership of the data.
> >
> For better or worse, JTS/GEOS already has well-defined sharing
> policies.  Performance-wise, it's probably for worse (in C land) - many
> of the intermediate data structures are designed to be usable on their
> own - which means that their components are shared.  And since they are
> mostly dynamic in nature, I think this implies that their component
> objects need to be heap allocated, correct?

Well, I'm too ignorant wrt GEOS to give a definitive answer, sorry. But it sounds right.

> Actually, I'm a bit puzzled by your code example.  If I understand it,
> you say that
> 
>  {
>         vector<bla> v;
>         // use v
>     }
> 
> results on stack-only memory usage.  But aren't vectors dynamically
> sized?  Doesn't the dynamically created memory get allocated from the
> heap?

The vector internally will allocate from the heap, yes, but the vector itself doesn't have to be allocated this way. If you avoid that you just remove half of the memory allocations...

Regards Hartmut

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