>Samuel-
>
>Also, consider that you have to (if you want to be a good citizen *s*), save the alias of the current work area, select your work area, and then reselect the original work area. Using the parameters makes the code so much cleaner, too.
>
>It's an interesting question you've asked, and if you do some benchmarks on it, let us know your results.
>
>>Just a small performance question about seek(). Is it faster to put the alias and the index in the seek call, or to constantly perform select aliases?\

Results:

Table Size: 100000. Integers Ranging from 1->100000 in sequence. Seeked for opposite ends of the table converging on the center then separating to the ends. (1,99998,3,99996,5,99994), 100000 seeks. Pentium 200, 64 Megs Ram. Apps running: VFP 5.0a, Outlook Express 5.0, Excel '97

Non Qualified Seek: select workarea, set order to, seek(expr)
Qualified Seek: seek(expr,workarea,order)

Method 1: Non Qualified Seek. Setting order and workarea back and forth each time. Easy 'Black Box'. Probably won't use in real life.

Method 2: Non Qualified Seek. Just setting order and work area each time. Just setting up the environment for yourself.

Method 3: Non Qualified Seek. Setting order and workarea once. Optimal case. Useful in a tight loop.

Method 4: Qualified Seek. Resetting order to a different tag each time. Comparable to Method 2, for changing work areas.

Method 5: Qualified Seek. Set 'wrong' order and workarea once. Classic Qualified Seek usage, most typical.

Method 6: Qualified Seek. Set 'right' order and workarea once. Optimal case. Exploring if Qualified Seeking in the current work area affects performance.

Method 7: Non Qualified Seek. Like Method One, using (macro substitution) for resetting workarea. A more realistic version of Method 1. Black Box.


Code with seek statements commented out.

Method 1 2 3 4* 5* 6* 7
1 3.014 1.419 0.464 0.516 0.431 0.438 2.077
2 2.810 1.320 0.407 0.484 0.403 0.411 1.910
3 2.844 1.323 0.439 0.486 0.405 0.440 1.883
Average 2.8893 1.3540 0.4367 0.4953 0.4130 0.4297 1.9567

Code with seek statements active.

1 8.255 5.874 3.755 6.301 6.094 5.433 6.605
2 8.267 5.838 3.750 6.277 6.121 5.448 6.701
3 8.283 5.886 3.797 6.372 6.104 5.444 6.716
Average 8.268 5.866 3.767 6.317 6.106 5.442 6.674

Difference 5.3790 4.5120 3.3307 5.8213 5.6933 5.0120 4.7173

Average seeks 4.4848
Average qualified seeks 5.5089


Using the "Difference" row to draw conclusions about the speed of a Qualified Seek Vs a Non Qualified Seek, it appears that a Qualified seek is the slower of the two. When you factor in the time it takes to setup the environment correctly (method 7 Vs method 5 and 6) it looks like the Qualified Seek is faster. Comparing 3 and 6, the Optimally "correct" use of both types of seeks the Non Qualified Seek is faster. the only case that the Non Qualified seek is faster is in 1 and 7, the cases where you restore the environment yourself. This makes sense, internally, the code is most likely just calling the procedures to set the environment back, avoiding the interpreter. It just so happens that cases 1 and 7 are the most frequent, so using the qualified seek will save you time, and when it doesn't save you time, it will save you code.

So basically, a Non Qualified Seek is faster. But once you add the overhead of cleaning up your environment, a Qualified Seek is faster.

If you would like to see the test code please just ask. (SRenkert@ECRSoft.com)



________________________________
Samuel Renkert
ECR Software Corporation
SRenkert@ECRSoft.com