Thanks for the idea.
My development machine has 8GB of memory. Most of the client machines that this app is to be installed on will have about half of that.
After I found that the size of the shape data was contributing to this issue, I modified some of the .dbf files to remove extraneous columns. This has helped limit the amount of memory that gets consumed by the call to .Table.Query(). It still surprises me that the entire .dbf file seems to be loaded in order to query it. This places a limit on us that I was not expecting.
I looked at the QuadTree index. The documentation states that this index is used for editing. I'll try it out to see if it helps.
I am currently using the FastMode property. I have assumed that it is helping with the drawing of the shapes, though I believe that the scale-dependent rendering logic helps a lot with that as well.
I had considered using SQLite with the dbf file. I did some testing with Spatialite (SQLite extended with spatial) and was encouraged, though I did find that the feature ID returned from a Spatialite tabular query was not the same featureID returned by the Shapefile.Table.Query() method. They differed by 1. The Spatialite tabular query was much faster, BTW.
Again, Thanks for the good ideas.
My development machine has 8GB of memory. Most of the client machines that this app is to be installed on will have about half of that.
After I found that the size of the shape data was contributing to this issue, I modified some of the .dbf files to remove extraneous columns. This has helped limit the amount of memory that gets consumed by the call to .Table.Query(). It still surprises me that the entire .dbf file seems to be loaded in order to query it. This places a limit on us that I was not expecting.
I looked at the QuadTree index. The documentation states that this index is used for editing. I'll try it out to see if it helps.
I am currently using the FastMode property. I have assumed that it is helping with the drawing of the shapes, though I believe that the scale-dependent rendering logic helps a lot with that as well.
I had considered using SQLite with the dbf file. I did some testing with Spatialite (SQLite extended with spatial) and was encouraged, though I did find that the feature ID returned from a Spatialite tabular query was not the same featureID returned by the Shapefile.Table.Query() method. They differed by 1. The Spatialite tabular query was much faster, BTW.
Again, Thanks for the good ideas.
