The DO WHILE in your example below is NOT Rushmore optimized. The reason it
is not optimized is first, the DO WHILE loop construct is not Rushmore
optimizable (the DO WHILE does not have a FOR clause). Therefore, a
comparable non optimized SCAN ... ENDSCAN would be:
USE table order MINE
SEEK whatever && whatever contains the key data in the defined in the MINE
tag
* If something contains the key data in the table, why would you check to
see if it is equal to somethingelse? I would think you would be checking
for "something = whatever. Then you would be rushmore optimized.
SCAN FOR something = somethingelse
ENDDO
The DO WHLE would be
USE table ORDER MINE
* The following would fail at the first entry point to the WHILE loop if
something contains the data in the table key unless somethingelse =
whatever.
SEEK whatever
DO WHILE NOT EOF() AND something = somthingelse
SKIP
ENDDO
* The Rushmore optimized versions of the above would be as follows:
USE table ORDER mine
whatever = criteria && The matching key in the table for multiple records.
SCAN FOR table.whatever = whatever && whatever in the table contains the key
data defined in the tag
ENDSCAN
In a nutshell, I have found the While loop is faster than a non-optimized
scan loop. I think you will find a substantial difference in speed between
a non-optimized scan loop and a while loop. The while loop should be
significantly faster. On the otherhand, I don't think you will find a
significant difference between an optimized scan loop and a while loop that
uses the rushmore technique of looping through matching keys in the
appropriate ORDER.
Wilson
-----Original Message-----
From: profox-admin .at. leafe DOT com [mailto:profox-admin@leafe.com]On Behalf Of
Dan Thompson
Sent: Friday, January 31, 2003 2:46 PM
To: profox .at. leafe DOT com
Subject: RE: is this a fair test? (SCAN vs DO WHILE)
I use DO WHILE most of the time as I have an INDEX that I can SEEK on, etc
USE table order MINE
SEEK whatever
DO WHILE something = somethingelse
ENDDO
-----Original Message-----
From: profox-admin@leafe.com [mailto:profox-admin .at. leafe DOT com]On Behalf Of
Wilson M. Kierstead
Sent: Friday, January 31, 2003 11:33 AM
To: profox@leafe.com
Subject: RE: is this a fair test? (SCAN vs DO WHILE)
<<Yes, but the point of a test is to come to a decision, in this case,
<<Should I use a scan or a dowhile loop for best speed?
<<And the answer is: It depends...
IMHO, it is usually always fair to state the answer is "It depends." This
generic answer is the point of doing the tests to start with.
The scan loop is designed to work with tables. The while loop is more
generic. You are right. It does depend. Things that should be checked
have to do with using rushmore or not. Not whether you have excluded a
required clause (!eof()) that would cause the while loop to fail. The topic
states "is this a fair test?" I stated it was not because eliminating the
eof() test throws something into the test that is not valid. One test run
fails while the other succeeds. Performing a while loop without the
appropriate logic to terminate the while loop changes the criteria since the
scan loop will succeed and the while loop will not succeed.
I would suggest testing both loops to skip through an indexed table using
rushmore and again, not using rushmore. All other criteria should be the
same regardless of which test is being executed.
Wilson
-----Original Message-----
From: profox-admin .at. leafe DOT com [mailto:profox-admin@leafe.com]On Behalf Of
Greg Gum
Sent: Friday, January 31, 2003 2:18 PM
To: profox .at. leafe DOT com
Subject: RE: is this a fair test? (SCAN vs DO WHILE)
Yes, but the point of a test is to come to a decision, in this case,
Should I use a scan or a dowhile loop for best speed?
And the answer is: It depends...
Greg
-----Original Message-----
From: Wilson M. Kierstead [mailto:wil@vfpbizapps.com]
Sent: Friday, January 31, 2003 1:13 PM
To: profox .at. leafe DOT com
Subject: RE: is this a fair test? (SCAN vs DO WHILE)
It seems you are missing the point. If you are going to do a fair test
against to loop instructions, the criteria has to be the same.
You cannot reasonably compare a DO WHILE with out the check of EOF()
against the SCAN loop. The scan loop intrinsically handles the eof
check. Therefore, an apples to apples test would be as follows:
* Test While loop -Start
SELECT table
ltstart = datetime()
GO TOP
do while !EOF()
skip
enddo
? datetime() - ltstart && show number of seconds taken to skip through
entire table
* Test While loop -End
* Test Scan loop -Start
SELECT table
ltstart = datetime()
SCAN
ENDSCAN
? datetime() - ltstart && show number of seconds taken to skip through
entire table
* Test Scan loop -End
Wilson KIerstead
-----Original Message-----
From: profox-admin@leafe.com [mailto:profox-admin .at. leafe DOT com]On Behalf Of
profox@cpvfug.org
Sent: Friday, January 31, 2003 9:35 AM
To: profox .at. leafe DOT com
Subject: RE: is this a fair test? (SCAN vs DO WHILE)
>>> I think what makes it slower is that Fox has to evaluate !EOF() each
time.
Oh yes, I agree 100%. However, I get a laugh when some folks just don't
want to believe it. I've come into apps that took forever and changing
to SCAN loops definitely improved the speed. It was an easy target
though: there were 3 nested DO WHILE !EOF() loops and changing them to
scan with index optimizations really made the difference.
Bo -- I see what you mean now. I changed to SET TALK OFF and the
difference was practically nil.
--Michael
Michael J. Babcock, MCP
Founder/President, Central PA Visual Foxpro User Group (CPVFUG) Upcoming
meetings:
- CHUCK URWILER, February 19, 2003
- DON VAN FLEET (.Net), April 16, 2003
- and more in the works!!!
http://www.cpvfug.org
mbabcock@cpvfug.org
"Code smarter, not harder."
[excessive quoting removed by server]
©2003 Wilson M. Kierstead |
