Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Set filter to not empty()
Message
De
02/01/2014 04:51:23
Walter Meester
HoogkarspelPays-Bas
 
 
À
02/01/2014 03:43:09
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows Server 2012
Network:
Windows 2008 Server
Database:
MS SQL Server
Application:
Web
Divers
Thread ID:
01591204
Message ID:
01591239
Vues:
58
>>>>Marcia, I am surprised that you can do this mistake. :-)
>>>>Set Top can be extremely slooooooow on a big table. Instead you should use Locate.

>>>>
>>>>As you may remember, Andy did several sessions on optimizing VFP code and this is what he wrote in his 2005 session:
>>>>
>>>>Locate vs Go Top
>>>>One of the conventions that has passed into FoxPro mythology is that a LOCATE command is faster than using GO TOP, and that by reversing the index order on a table and using LOCATE performance is better than just using the GO BOTTOM command. However, as the following table shows, this is only true when you are using Filters and is more to do with the fact that the LOCATE command is optimizable (as shown above) than anything else. In VFP 7.0 the difference between the two commands is smaller than in previous versions anyway. Of course, GO TOP and GO BOTTOM retain one huge advantage over LOCATE because they can take an IN alias clause, thereby obviating the need to change work areas.
>>>>
>>>>
>>>>Methodology                          GO TOP   LOCATE      GO BOTTOM	INVERT INDEX  AND  LOCATE
>>>>No Filter	                                0.030	0.060	0.300	0.070
>>>>Filter Not Optimizable	        0.010	0.020	0.100	0.071
>>>>Filter Partially Optimizable	0.010	< 0.001	0.952	0.140
>>>>Filter Fully Optimizable	        0.010	< 0.001	1.021	0.140
>>>>
>>>
>>>Since a filter is in deed used in this case, Locate would be faster if the table has an index tag on Empty().
>>
>>This is only applicable if there are a lot of delete records. If there are none, GO TOP and GO BOTTOM are fast in any case because they do not have the overhead of rushmore.
>
>Deleted records or not, my conclusion is correct. The important point here is Set Filter, and whether the filter expression matches an index tag or not. If you want to argue, that's fine, but I don't want to participate.

I was not awake this morning, you are correct. If a rushmore optimizable filter is in effect the LOCATE can be faster than GO TOP. Of course it depends on how many records from the top do not match the filter though as rushmore might drag its own overhead into the matter.
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform