<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
Hartmut Kaiser wrote:
<blockquote cite="mid:4a9c56d5.21d7720a.64a3.081d@mx.google.com"
type="cite">
<blockquote type="cite">
<pre wrap="">Martin Davis wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
>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.
</pre>
</blockquote>
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.<br>
<br>
Regards, Barend<br>
<br>
<br>
</body>
</html>