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

[Martin Davis]

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
> 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
>>
>>     
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022