AND you don't get the "damn I forgot the SKIP again"!!!

>From my experience, SCAN is faster than DO WHILE. I don't remember a case when DO WHILE was faster, but, it's also true that I rarely did such tests. :)
>
>Basically, there should be no reason to have a SCAN WHILE slower than DO WHILE. But you may have a SCAN FOR slower than DO WHILE, as well as a DO WHILE slower than SCAN FOR.
>
>I would change the DO WHILEs with SCANs without second thoughts. First, SCAN is more flexible and gives you more chances to optimize. Second, if the current area is changed and restored inside the DO WHILE (very usual in programs that use a lot of DO WHILEs), the SCAN will be faster because it eliminates the need to restore the current area.
>
>Vlad
>
>>I have been given the task of optimizing the performance of a block of code (too large to be copied here). Currently, the code contains a mix of SCAN..ENDSCAN loops and DO WHILE..ENDDO loops. Some of the WHILE clauses are not Rushmore-optimized, so normally my first step would be to replace these with optimized statements. In some cases, however, this may not be possible.
>>
>>While I'm at it, I was going to replace the DO WHILE..ENDDO loops with SCAN..ENDSCAN. However, someone mentioned to me that when using non-optimized statements, a DO WHILE..ENDDO can actually give better performance than a SCAN..ENDSCAN. Is this true? I've always used SCAN..ENDSCAN, but some of the legacy code I'm looking at uses DO WHILE..ENDDO.
>>
>>Bill