[geos-devel] [Fwd: [Boost-users] [boost] Formal Review: Boost.Polygon starts today August 24, 2009]

[Barend Gehrels]

Hartmut Kaiser wrote:
>> Martin Davis wrote:
>>     
>>> Hmmm... GEOS comes off rather badly compared to GGL.  Is that because
>>>  of memory access issues?  Or perhaps the fact that less code is
>>> inlined?
>>>       
>> It's hard to judge, but I'm quite sure inlining is only a small and
>> minor optimisation available.
>> GEOS and GGL follow completely different programming paradigms.
>> GGL is strongly based on static polymorphism resolved and calculated in
>> compile-time. This increases changes that compilers will apply finest
>> possible optimisations.
>>     
>
> >From what I've seen in GEOS and GGL, GEOS is mostly relying on dynamic
> memory allocation, where GGL tries to avoid that. GEOS relies on runtime
> polymorphism, where GGL relies on compile time (static polymorphism). GEOS
> is built using Java-ish constructs, where GGL is build the C++ way...
>
> All of this influences the runtime behavior, but there might be more
> reasons. Please note, I didn't do any thorough analysis, all of this is just
> guessing.
>   
I do not know GEOS very well but I think that Hartmut is right here. GGL 
uses the std-library for storage of coordinates. If I'm right, GEOS 
calls a memory allocation for every point (of a polygon). And indeed GGL 
uses static polymorphism. The consequence of this is also that there is 
no polygon.area() function, but an area(polygon) function, taking any 
polygon which fulfills the polygon concept.

Regards, Barend


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geos-devel/attachments/20090902/525bb3a0/attachment.html