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

[strk at refractions.net]

On Mon, Jan 31, 2005 at 08:14:27PM -0500, Norman Vine wrote:
> Martin Davis writes:
> >
> > Norman Vine
> > > 
> > > Martin Davis writes:
> > > > 
> > > > 
> > > > That was pretty much my point - smart pointers alone don't produce 
> > > > memory efficiency, they just make the code safer (and hopefully 
> > > > easier).
> > > 
> > > Well they are a little faster then any garbage collection 
> > > routine could ever be but you are right 'speed issues' aren't 
> > > why they are used.
> > > 
> > > Has anyone profiled the code recently,  without profiling 
> > > statistics optimization discussions are really just guesswork.
> > 
> > Something to note here is that the original profiling numbers given by
> > strk were based on the buffer algorithm.  Buffer is by far the most
> > complex algorithm in JTS, and inherently has to create lots of new
> > coordinate sequences (amongst other things).  There may be no way to
> > remove this requirement, in which case the only way to improve the speed
> > is to increase the speed of memory allocation.
> 
> One thing that would probably speed things a bit is to inline the
> trivial constructors and destructors :-)

I would do this, but is it possible to inline functions w/out
breaking ABI ? Will using the 'inline' keyword be enough ?

--strk;

> 
> It might be worth looking into special memory managers but AFAICT 
> most of the 'coordinates' are actually stored in STL vectors and these 
> are generally about as efficient as you can get at minimizing allocation
> costs.
> 
> Norman
> 
> 
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel