Hi Jim,

Agree on the test. I just wanted to try the most basic to begin with. I tried it after reading this with a WHERE and a ORDER clause and the results were reversed. Also, see my reply to Charlie S.

Cheers,

>Hi Colin,
>
>yes, that is confusing for sure!
>
>Hopefully those who got real deep into this will read and respond.
>
>Some guesses I would offer are:
>
>Maybe a SELECT * is not the best test. Seems to me that a WHERE clause would be required to get RUSHMORE really applying itself.
>
>Maybe 37000 records with slightly less than 5% deleted is on the cusp of where the characteristic changes. Seems to me that most of the benchmarking I read was with none or only very few deleted records.
>
>
>What I do know is thta I am no longer using a TAG on Deleted() by default.
>
>Hopefully,
>
>Jim N
>
>>Jim,
>>
>>I find all this very confusing/frustrating at times because I look at the results reported by Andrew and then I do some simple testing that gives the opposite results. Test was mytable with 37000+ records and no index tag on DELETED(). I ran SELECT * FROM mytable 3 times in FP2.5 DOS and VFP6 SP3 and FP2.5 results were 5.11, 3.95, and 4.39 seconds and VFP results were 1.14, 2.39, 1.55 seconds. I then added a tag on DELETED() (about 2000 records are deleted) and the results were FP2.5 0.05, 0.01, and 0.00 seconds and VFP 0.01, 0.00, 0.01 seconds
>>
>>So for this scenario I can say VFP is generally faster than FP2.5 and the DELETED() tag was a benefit to both. But, this obviously can't be a blanket statement because in some cases it has been reported as detrimental. So how are we to know when to use it and when not to?
>>
>>>Thanks for that Andrew.
>>>
>>>It still baffles me that exactly the opposite used to be reported - a slow response would become lightening fast when a TAG on Deleted() was ADDED.
>>>
>>>Still smells to me (that something changed sometime ago).
>>>
>>>Cheers,
>>>
>>>Jim N
>>>
>>>>I can give you a real-world example of my playing with the DELETED() index. A few months ago I was reading here the debate on using a DELETED() index tag and decided to give it a shot and see how it worked. Just 2 weeks ago, I was desperately trying to figure out how to speed up a form that uses a parameterized view to fill a simple grid on this form. The view has only 1 table (around 20k records, < 5% deleted) and 4 filter parameters. The application is networked.
>>>>
>>>>I remembered the DELETED() tag in the table and took it out. The requery time went from 28 seconds to 11 seconds. No other changes in the tables/views or program code. The speed difference of adding a record wasn't really noticable.
>>>>
>>>>
>>>>- A Hilton
>>>>
>>>>
>>>>>>I think it would be very interesting to see the tests that convinced Walter and yourself of the relative uselessness of the DELETE() tag performed in Fox 2x. I do not (and never have) own a copy, so I can't test myself.
>>>>>>
>>>>>>But if you are correct, and something changed along the way to negate the benefits of DELETE() tags, performance differences should be pretty evident.
>>>>>
>>>>>
>>>>>Just a point about testing: it should be done on a network. From my investigation when you update a table on a stand-alone machine the Rushmore bit maps are not reloaded. (Presumably they are just updated.) On a network if any workstation changes the table then every (other?) workstation must reload the Rushmore bit maps including the deleted() map.
>>>>>
>>>>>Peter