[geos-devel] JTS/GEOS performance - smart-ptr vs ref counting

[Martin Davis]

It's just occurred to me that a classic issue with ref-counting is being
able to handle self-referential data structures.  Some of the data
structures in JTS/GEOS are inherently self-referential (e.g. topology
graphs).  Is there a standard pattern for coping with this kind of
problem?

Failing this, might it be better to look at a garbage-collected
approach?

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: Martin Davis 
> Sent: January 31, 2005 4:35 PM
> To: GEOS Development List
> Subject: RE: [geos-devel] JTS/GEOS performance - smart-ptr vs 
> ref counting
> 
> 
> That was pretty much my point - smart pointers alone don't 
> produce memory efficiency, they just make the code safer (and 
> hopefully easier).
> 
> 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: Chapman, Martin [mailto:MChapman at sanz.com]
> > Sent: January 31, 2005 4:18 PM
> > To: GEOS Development List
> > Subject: RE: [geos-devel] JTS/GEOS performance
> > 
> > 
> > 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
> > 
> > _______________________________________________
> > 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
>