<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<blockquote cite="mid:20090902095325.GH40687@keybit.net" type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
getAt is a virtual function, can't be inlined.
</pre>
</blockquote>
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. <br>
<br>
A (probably) working way to have less virtual calls (for area) then
would be changing this:<br>
double bx=ring->getAt(i).x;<br>
double by=ring->getAt(i).y;<br>
double cx=ring->getAt(i+1).x;<br>
double cy=ring->getAt(i+1).y;<br>
<br>
to this: Coordinate const& c = ring->getAt(i + 1 );<br>
double cx = c.x, cy = c.y;<br>
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.<br>
<br>
This just in search of what would be the bottle neck, because the area
algorithm itself is extremely simple. <br>
<br>
<br>
<br>
<blockquote cite="mid:20090902095325.GH40687@keybit.net" type="cite">
<pre wrap="">Templates would make it a lot better, but far away
from 1:1 mapping with Java.
</pre>
</blockquote>
Sure, though Java also have templates now<br>
<br>
<blockquote cite="mid:20090902095325.GH40687@keybit.net" type="cite">
<pre wrap="">
Beside, how do you handle memory management in GGL ?
</pre>
</blockquote>
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<br>
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.<br>
<br>
Regards, Barend<br>
<br>
</body>
</html>