[geos-devel] [Fwd: [Boost-users] [boost] Formal Review: Boost.Polygon
starts today August 24, 2009]
Barend.Gehrels at geodan.nl
Wed Sep 2 07:45:37 EDT 2009
>> 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:
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the geos-devel