[geos-devel] Updated timings/profiling.

[strk at refractions.net]

On Tue, Feb 01, 2005 at 04:55:46PM +0100, strk at refractions.net wrote:
> On Fri, Jan 28, 2005 at 01:19:55PM +0100, strk at refractions.net wrote:
> > Some time ago I've been researching about GEOS performance
> > problems as related to JTS. Attached is a shapefile and an .xml
> > test you can use to compare the two.
> > 
> > JTS does not support buffers tests, so you'll need to use another
> > method for that. I used JUMP, which reports computation time.
> > 
> > Well. The operation is a buffer(polygon, 2000).
> > 
> >  JTS:  18 seconds
> > GEOS: 574 seconds (9 minutes, 34 secs)
> 
> I've found out I was using non-optimized builds (-O0).
> With -O2 GEOS timing reduces to 63 seconds.

Timing is now 43 seconds (from 63). We are getting closer ...

I've done other optimizations of the code.
The bigger one is probably inlining of most Envelope methods,
but I've also added some preallocations for standard containers
(mostly in indexSTRtree).

Our bottleneck now is STRtree::STRIntersectsOp::intersects(), with
15.35% of time spent. This function basically calls the inlined
Envelope::intersects, so not much to optimize there, and no inlining
possible. 

I wonder if checking for intersection 45281976 times is really correct
or our indexes are broken... 

First line of flat profile:

Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls   s/call   s/call  name
 15.35     14.27    14.27 45281976     0.00     0.00  geos::STRtree::STRIntersectsOp::intersects(void const*, void const*)
  7.73     21.46     7.19                             geos::AbstractSTRtree::query(void const*)
  4.28     25.44     3.98    28602     0.00     0.00  geos::RobustLineIntersector::computeIntersect(geos::Coordinate const&, geos::Coordinate const&, geos::Coordinate const&, geos::Coordinate const&)
  3.72     28.90     3.46 40923120     0.00     0.00  geos::DefaultCoordinateSequence::add(geos::Coordinate const&)

--strk;


> 
> Still worth profiling, but JTS/GEOS are much closer.
> 
> Most of the time is spent in MCQuadtreeNoder::intersectChains().
> 
> --strk;
> 
> > 
> > GEOS computation keeps the CPU pretty busy (98.2-99.8%)
> > and takes up to about 170 MB of ram
> > 
> > JTS seems to use 3 threads, the bigger using at most 80% 
> > of CPU, but most of the time far below that point.
> > JUMP reports 104MB committed, but I'm not sure about the meaning.
> > 
> > For GEOS, valgrind reports (with buffer 500):
> >  malloc/free: 2982697 allocs, 2982697 frees, 924407212 bytes allocated.
> > 
> > How much do you think this wild allocation negatively influence the
> > poor performance of GEOS ?
> > 
> > --strk;
> > _______________________________________________
> > 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