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

Martin Davis mbdavis at VividSolutions.com
Mon Jan 31 19:35:28 EST 2005


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
> 



More information about the geos-devel mailing list