Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
ARGHH! big table killing VFP - need strategy help!
Message
From
12/08/1999 10:33:05
 
 
To
12/08/1999 03:47:01
Walter Meester
HoogkarspelNetherlands
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00250826
Message ID:
00252961
Views:
19
Hi Walter,

Well, that is both interesting and disconcerting at the same time!

It really does have me wondering how so many people could have reported 'now running nice and fast, as expected' (over several years now) once told to try an index on DELETED() and doing so [because I am willing to bet that the vast majority of tables have only a very small percentage of deleted records].

I would agree that running over a modem (a much more recent phenomenon) would tend to highlight this more directly, but I still have a problem rationalizing the situation.

I suppose that you will now install VFP on that machine. If you do, is a repeat of the exact test possible (though of course I know that you did enough prior testing to KNOW that it was most similar on a "virgin" FPD machine).

Thanks for that, Walter,

Jim N


>Jim,
>
>I Tested the DELETED() tag behaviour for FPW 2.6 in the following circumstances.
>
>- On a NT-server machine, No other Fox versions installed.
>- Over a 10 mb lan network (not used by other means than this experiment).
>- With a SQL SELECT SUM() FROM ... WHERE Expression (Expression is rushmore optimizable)
>- With a SQL SELECT *, .T. FROM ... WHERE Expression (Expression is rushmore optimizable)
>- I used two identical tables: one with the index on deleted() (TAGGED) the other not (NONTAGGED).
>- The tables were not fragmented, the indexes balanced with reindex.
>- The tables both are approx 17MB, 152.000 records.
>- I did test the performance with 5%, 10% and 20% deleted records.
>
>When the queries run for the first time the difference between performance between the deleted()
>tagged and the non tagged table where as follows: The TAGGED table was a little slower when the amount of records dropped below the 10%
>and was a bit faster when the amount of records was above the 10%. This may sound reasonable because the extra deleted() tag is dragged over the network while it's benefit is virtually none when there are just a few deleted records.
>
>For the record: All the queries run in approx 11 seconds and the variation was about a few tenths of a second.
>
>
>When the index was alread on the client, the TAGGED queries run almost alway's according the following formula.
>- Perforance gain in seconds = Totaltime NONTAGGED query * deleterecords% * OverheadUsingDeletedTag(approx .60)
>
>Though I know that this won't prove anything about the deleted() tag in all cirumstances, but It gives me the impression that not muchs
>has changed since the FP(W) 2.x days
>
>Walter,
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform