[Fwd: Re: [geos-devel] Benchmark between various geometry libraries]

Paul Ramsey pramsey at cleverelephant.ca
Wed Nov 18 17:59:41 EST 2009


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 (a statically defined geometry
factory). By the same token, we could probably bolt GEOS onto a memory
pool implementation from APR or somewhere else and see how much things
change.

P.

On Wed, Nov 18, 2009 at 2:38 PM, Martin Davis <mbdavis at refractions.net> wrote:
> 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 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?
>
> 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?
> --
> Martin Davis
> Senior Technical Architect
> Refractions Research, Inc.
> (250) 383-3022
>
>
>
>
> --
> Martin Davis
> Senior Technical Architect
> Refractions Research, Inc.
> (250) 383-3022
>
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>


More information about the geos-devel mailing list