Slow Query Performance with Shapefile issue

[MorganFraser]

Hello

I'm trying to perform a spatial query and I'm experiencing very slow performance when using ESRI Shapefiles versus VPF VMap data. This is especially true when the query returns no results which takes much longer than if results are returned.

I'm doing this all in C++.

I'm calling ITable->Search() which takes no time, but the first ICursor->NextRow() call then is taking the time. The passed IQueryFilter is from a SpatialFilter object and I've passed a simple polygon with 4 corners (actually a rectangle). The spatial relation I'm using on the filter is esriGeoDatabase::esriSpatialRelIntersects.

On my particular example dataset (the roads layer), when there are no features within the query polygon, it takes 844ms with the Shapefile, and 0ms with the VMap data. If there are features in the query polygon, it takes 156ms with the shapefile, and ~40ms with the VMap data.

Is there a reason why empty queries are so slow for shapefiles?
Is there a way that I can determine if the query will return no results without calling the NextRow() function?

Thanks for any help

[KirkKuykendall]

Does your shapefile have a spatial index?

As I recall, a shapefile index consists of a minimum bounding rectangle (MBR) for each road.  If you had, for example, a nationwide shapefile of interstate highways where each highway is a single feature, queries would perform slower than a shapefile of the same highways split at state boundaries.  With the unsplit shapefile the search intersects many more MBR's.  For each intersected MBR further processing (and file i/o) is needed to see if there really is an intersection.  With highways split at state boundaries, fewer MBR intersections occur.

You also might consider using esriSpatialRelEnvelopeIntersects.

Also try setting IQueryfilter.SubFields to just the fields you need, and consider passing TRUE for Search recycling arg.

Is there a way that I can determine if the query will return no results without calling the NextRow() function?

Try IFeatureclass.FeatureCount

[MorganFraser]

Just as a followup, I figured out the problem.
The spatial index files were originally created using ArcView 3.1. Deleting the existing SBN/SBX files and recreating them using the ArcGIS 9.3.1 engine solved the problem with the performance.