Performance of Scanning a Quadtree Index

[Brock Anderson]

Indeed, Mapserver is definitely using my index.  I confirmed by deleting 
it, and re-testing. 

The problem scenario really stands out with big data sets.  My test data 
set has 4 million polygons, so probably too large to attach to a bug 
report.  I'll see if I can find a smaller data set that exposes the problem.

I'll also try to dig up the Geoserver code which handles the index scan.

I'm going to wait on creating that ticket until I've got more info...

Brock

Daniel Morissette wrote:
> Brock Anderson wrote:
>>
>> I then make a simple WMS request to fetch exactly 1000 features 
>> (limited by a bbox) from the layer.  Mapserver take about 500ms. 
>> Seems a bit high.
>> Geoserver can draw the exact same data, using the *same .qix* index 
>> in about 150ms.  Naturally I made every effort to keep the comparison 
>> fair.  No reprojection in either case, nearly identical styling, etc.
>>
>
> Ouch! That's no good. Have you verified that MapServer indeed finds 
> the .qix and uses it (perhaps by removing the file and seeing that it 
> then takes several seconds to render the map)?
>
>> As a further comparison I noticed that Mapserver and Geoserver are 
>> nearly equal for fetching/drawing 1000 features from a smaller data 
>> set of just 10,000.  Response time there is more like 120ms.
>> So on large shapefile data sets Geoserver's index scanning seems to 
>> be substantially faster.  Are there any map file options that might 
>> improve performance?  Could it be that Geoserver simply has a faster 
>> implementation for traversing the quadtree?
>>
>
> Could be. In which case we should compare the two implementations to 
> figure what GeoServer does better, and fix MapServer.
>
> Could you please file a ticket about this with the info that was in 
> your email? Are you able to share the dataset that you use to 
> reproduce this? Also, if you can include a link to the GeoServer 
> source file(s) that handles the .qix reading in the ticket so that we 
> know where to look to compare the two implementations then that would 
> be great. I will not have time to look at this before 5.0 is released, 
> but maybe someone else will... or at a minimum we need to make sure we 
> try to address this in 5.2.
>
> Thanks
>
> Daniel