[geos-devel] JTS/GEOS performance

Chapman, Martin MChapman at sanz.com
Mon Jan 31 19:17:30 EST 2005


Martin,

Smart pointers are one thing and ref-counting (garbage collection) are
two different but related things.

Smart pointers help prevent memory leaks.  A smart pointer is always
created on the stack, when the function ends they always go out of scope
and their destructors delete their encapsulated pointer...therefore, if
all heap data is wrapped by a smart pointer, if the function crashes you
are guaranteed that the heap memory will be de-allocated because the
smart pointer will always be destroyed and will call it's destructor.
This actually means more vars on the stack, but less chance for
mem-leaks. 

Ref-counting allows multiple objects to share pointers to the same
object without the fear of some other object deleting that object before
you are done using it, and allows you to safely pass heap data across
function boundaries.  This can save huge amounts of memory and
debugging.  For example...if you have a million geoms that all have a
pointer to the same spatial reference class then you only need one SRS
class versus a million of them.  The SRS class refcount will be a
million and is guaranteed to be around until the last geom decrements
the ref count to zero.  Also, this way you can easily and quickly change
a prop on the SRS class that is immediately available to all million
geoms.  You can also, easily re-assign the SRS of an individual geom
without disrupting the other 999,999 geoms.  

So the short answer is, an enterprise api should have both smart
pointers and ref-counting available as an option.  

The email I just sent before this one has code examples of a
smart-pointer template class that does both.  It's based after MS COM's
CComPtr<> class, but is ansi and will run cross platform.  It's small,
light-weight, polymorphic and works great.  Geos definitely needs this,
but it's not going to make your app faster, just more memory
efficient...and you won't have to be calling "delete" all over the place
anymore.

Increasing speed is all about looping and allocating/de-allocating in
your app.  The more times you loop through coords and alloc/dealloc you
are consuming lots of clock cycles.  Think about what it takes to alloc
20 classes for each loop in a million features...if you look at the
disassembler you would be amazed.

Martin


-----Original Message-----
From: Martin Davis [mailto:mbdavis at VividSolutions.com] 
Sent: Monday, January 31, 2005 3:50 PM
To: GEOS Development List
Subject: RE: [geos-devel] JTS/GEOS performance


I can see how smart pointers can help with program correctness.  Do they
help with performance?  

Martin Davis, Senior Technical Architect
Vivid Solutions Inc.      www.vividsolutions.com
Suite #1A-2328 Government Street Victoria, B.C. V8T 5G5
Phone: (250) 385 6040 - Local 308 Fax: (250) 385 6046


> -----Original Message-----
> From: Norman Vine [mailto:nhv at cape.com]
> Sent: January 31, 2005 11:31 AM
> To: GEOS Development List
> Subject: RE: [geos-devel] JTS/GEOS performance
> 
> 
> Martin Davis writes:
> > 
> > Hmmm.  This seems fundamentally the wrong approach.  JTS
> does not need
> > the flexibility of linked lists inside CoordinateSequences.
>  It sounds
> > like you are trying to build a garbage-collected memory management
> > layer.  This may be the only reasonable solution.  However, rather 
> > than hacking this into the existing code in an obtrusive 
> kind of way,
> > it would be nicer to look for a clean, layered solution.  Are there
> > any open source GC packages for C++?
> 
> There are several quality OpenSource C++ Memory Managers but
> ... This is *exactly* the kind of thing that smart_pointers 
> have made sort of obsolete  :-)
> 
http://boost.org/libs/smart_ptr/smart_ptr.htm

Norman
_______________________________________________
geos-devel mailing list
geos-devel at geos.refractions.net
http://geos.refractions.net/mailman/listinfo/geos-devel
_______________________________________________
geos-devel mailing list
geos-devel at geos.refractions.net
http://geos.refractions.net/mailman/listinfo/geos-devel



More information about the geos-devel mailing list