[postgis-devel] Re: postgis/geos profiling

[strk at refractions.net]

On Fri, Sep 24, 2004 at 09:51:53AM -0700, Martin Davis wrote:
> Hmmm...  It seems odd that the times for distance() are relatively
> independent of the number of 'true' cases.  Any idea why this should be?
> The times for intersects are almost exactly proportional to the number
> of true results, which is what I would expect.

The distance() function computes the minimum 2d distance
between two geometries.
Since the "minimum" distance cannot be smaller then 0, as
soon as an intersection is found "distance()" returns 0.

The segment scanner might encountered an intersection only
in the last scanned tuple of segments.
For example the last segment of the last hole of the polygon
intersects the last segment of the linestring...

Or it could catch it immediately.

False results, on the other hand, force distance() to scan the whole
segment set before giving an answer (never short-cut).
True results represent cases in which distance() used it's internal
short-circuit.

Try analyzing the output under this light... 

--strk;

> 
> Maybe it's not right just counting the number of "true" results.  After
> all, both methods spend time computing for "false" results as well.
> Although I guess the index removes most of the false results.  Is there
> any way to get a count of how many tests were actually performed by the
> functions?
> 
> 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: strk at refractions.net [mailto:strk at refractions.net] 
> > Sent: September 24, 2004 5:39 AM
> > To: Martin Davis
> > Cc: postgis-devel at postgis.refractions.net
> > Subject: Re: postgis/geos profiling
> > 
> > 
> > Some profiling over distance() vs intersects().
> > 
> > The profiler script is in CVS (utils/profile_intersects.pl).
> > 
> > The scripts takes two spatial tables.
> > The first is for extent extraction.
> > The extent of first table is subdivided in BPSxBPS cells
> > and each of the features in second spatial table is
> > checked for intersection with each cell.
> > 
> >   - index scan is been disabled ! -
> > 
> > At the end of each BPS query loop a summary is printed 
> > containing worst and best runs in percentile one over the 
> > other (distance, intersects).
> > 
> > 't' is the number of queries returning 'true'.
> > 
> >   Type: MULTILINESTRING
> >   Rows: 3183
> >   bps   t       intr    dist    intr/dist
> > ----------------------------------------------------------
> >     2   371     145254  152154  0.95
> >     2   769     225747  159403  1.41
> >     2   1801    467103  149191  3.13
> >     2   283     118823  155096  0.76
> >     2    (min/max/avg)          0.76    3.13    1.56
> >     2   worst   313%    131%
> >     2   best    31%     76%
> > 
> > These are large boxes. The cell which contains MORE 
> > intersecting features is the one in which intersects() does 
> > is worst job. The one with less intersecting cells give the 
> > best intersects() run.
> > 
> >   Rows: 3183
> >   bps   t       intr    dist    intr/dist
> > ----------------------------------------------------------
> >     3   0       49965   158799  0.31
> >     3   346     134842  161126  0.83
> >     3   325     118629  165073  0.71
> >     3   804     236623  153393  1.54
> >     3   459     163660  156635  1.04
> >     3   160     87627   161721  0.54
> >     3   872     262444  156008  1.68
> >     3   243     109996  159614  0.68
> >     3   51      61193   162184  0.37
> >     3    (min/max/avg)          0.31    1.68    0.85
> >     3   worst   168%    322%
> >     3   best    59%     31%
> > 
> > Here the relation between true values and intr/dist factor 
> > still holds true. 
> > 
> > --strk;
> >