Larry,

>>A blind LOCATE is the same as LOCATE FOR .T.. The Filter is optimized, as is >the deleted condition if the indexes exist.
>
>So why if we are talking about optimization does a locate nooptimize run 250% faster than a locate on a 40K record table and a 100K record table? This is done on tables without filters.

A non optimized locate on a table without filters will directly go to the first record, If indexes exist, rushmore get's to work, and will come to the conclusion that it should go to the first record. The delay is caused by rushmore.

If a filter exist, rushmore could gain performance because it can faster determine to which record it must jump.

Also, when there are indexes on the table, rushmore gets to work, but in some cases the rushmore mechanism takes more time finding the recordnumber than sequentual scanning the table. This is particular the cases when there are not many records and/or all the records are buffered by the OS.

From my student time I was told not to index tables if they were smaller than about 10 records, because the time needed to optimize the query would be more than just sequentual scanning. I'd say this still is true for FoxPro tables.

In fact this whole thing is related to the deleted tag thing where the time to process the deleted() index would cost more time (and probably network traffic) than filtering out those few deleted records when they're already requested from the fileserver.

The point is that rushmore tries to reduce I/O (either network or your local HD) by predetermining the records to be requested with the help of indexes (which are structured and smaller than the actual table thus minimizing I/O). But when a lot is already buffered you might be better of without rushmore.

Walter,


>Actually I ran the same test with a filter that did not match the index expression and the findings were about the same.