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