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

[Barend Gehrels]

>> I just debugged the Geos area routine, what could then be the reason 
>> that it is relatively slow? It might be that it is accessed as a vector, 
>> indeed, but not as an iterator, so getting points using "return 
>> (*vect)[pos]" is not efficient as it could be using iterators. Besides 
>> that it is probably no problem to make the getAt function inline.
>>     
>
> getAt is a virtual function, can't be inlined.
>   
Right, I debugged in CoordinateArraySequence, where it is not denoted 
virtual (the overloaded version is...), but I now saw that its parent 
indeed is virtual.

A (probably) working way to have less virtual calls (for area) then 
would be changing this:
        double bx=ring->getAt(i).x;
        double by=ring->getAt(i).y;
        double cx=ring->getAt(i+1).x;
        double cy=ring->getAt(i+1).y;

to this: Coordinate const& c = ring->getAt(i + 1 );
double cx = c.x, cy = c.y;
and have a previous_coordinate (b) for the getAt(i). Would save 3 
virtual calls + 3 times non-iterator-based vector access... I didn't try it.

This just in search of what would be the bottle neck, because the area 
algorithm itself is extremely simple.



> Templates would make it a lot better, but far away 
> from 1:1 mapping with Java.
>   
Sure, though Java also have templates now

> Beside, how do you handle memory management in GGL ?
>   
1) Using the std:: library. Where it is an optional template parameter, 
so you can have polygon<point> but also polygon<point, std::deque> for 
if you decide that you want a deque instead of a vector
2) Using concepts, actually a polygon or linestring can be anything as 
long as it fullfiles the concept. So having an iterator (for linestring 
that is enough), having traits te denote exterior/interior ring 
handling. In this way our library does not even now what is below the 
surface, it just uses it.

Regards, Barend

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