[geos-devel] Dev news (GEOS-2.2.0 and GEOS-HEAD)

strk at refractions.net strk at refractions.net
Tue Nov 29 12:48:05 EST 2005


--[ About the 2.x.x branch ]--

I've defined a new branch in CVS: branch-2-2
That is where GEOS-2.2.0 will come out from.

There, I've backported WKB io and CAPI from head.
So next release will be GEOS-2.2.0, including:
	- libgeos.so.2.2.0
	- libgeos_c.so.1.0.0

Changes since last release (2.1.4):
	- Performance improvement in OverlayOp::insertUniqueEdge()
	- CoordinateSequence copy removal in EdgeRing
	- Minor memory allocation improvements
	- Higher dimensions interface for CoordinateSequence
	- Added getCoordinatesRO for Point class
	- NEW WKB IO
	- NEW Simplified and stabler C API

About ABI protection: the only cases of clas definition 
change are in CoordinateSequence and CoordinateSequenceFactory
(and subclasses). I've appended public methods as suggested
by Frank W. Tests against postgis succeed (no ABI problems).
If you can test this before release it would be nice.

Note that if you link your application against the C-API you won't
need to rebuild it when upgrading to next (hopefully any future)
major release.

--[ About the HEAD branch ]--

The code in HEAD branch is known to run much faster then then one
that will be shipped with 2.2.0. Many small optimizations did
a lot in terms of performances.

Unfortunately most changes where ABI breaking, and thust the need
for an abstraction. Before releasing code from HEAD I'd like
to provide some sort of API reduction for C++ clients as well.

In any case, since ABI and part of internal API is changed
I'd like to push the optimizations further, possibly with
help by the community.

Optimizations introduced so far are:

	- heap allocations reduction

	  Most objects allocate objects w/out a real reason.
	  This forces use of try{}catch{} blocks for the
	  sole purpose of not-leaking and, worst, result
	  in a working set a lot fragmentized.
	  Most of these objects are standard containers, which
	  will allocate memory themself when added-to.
	  In addition, vectors<> are rarely .reserved(), which
	  brings to more allocations and memcpy then required.

	- coordinate copies reduction

	  Coordinate copies are still the most time-consuming
	  part. They are currently inlined so you don't see it.
	  I've provided geom.h with a macro, setting which provides
	  non-inlined assignment and copy-ctors.
	  That lets we see where do copy happens.
	  I removed a few obvious copies (most notably in
	  NodeFactories, which did make a temporary Coordinate
	  copy for each new node in a Geometrygraph - ABI breaking
	  change) but much more could be removed by use of
	  Coordinate pointers (or refs) in GraphComponents.
	  The latter would require a fair amount of time for
	  reorganization of the code.

	- appropriate container choice and usage

	  Some classes use vector<> when a set<> or map<> should
	  be used instead. This was the case for BufferSubgraph,
	  EdgeIntersectionList and EdgeEndStar. Not all classes
	  have been scanned yet.

Head branch is bound to release 3.0.0.


--strk; 

 /"\    ASCII Ribbon Campaign
 \ /    Respect for open standards
  X     No HTML/RTF in email
 / \    No M$ Word docs in email




More information about the geos-devel mailing list