[1] [2]
The Visual FoxPro documentation discusses an _COVERAGE memory variable and states that it contains the Code Coverage Analyzer, COVERAGE.APP, by default, installed in the root directory of the VFP installation. Unfortunately, it seems that the Analyzer was dropped from the product. However, knowing the structure of the underlying tables, it is not impossible to write our own.
When an application is assigned to _COVERAGE, when Code Coverage is selected from the Debugger Tools menu, the "Generate" option is available to perform your own code coverage analysis.
Step One of our sample code coverage analyzer accepts the setting of the code coverage log file and the name of the command to run. This example is set to DO a PRG file, but it would not be a difficult task to expand this to support other options, such as forms.
Figure 1: The Code Coverage Analyzer first tab allows you to run code coverage against your code
All code for the Code Coverage Analyzer is included in the proceedings disks.
Analyzing the results of the code coverage process indicate that, like the problems run into with benchmarking, the accuracy of the time is questionable at best. Typically, 94 - 98% of the times recorded by the process are zero, and the remaining few percent seem to vary widely. Despite this, on large enough samples, there does seem to be some validity to comparing the average non-zero times of various commands. The presentation will show how code coverage was used to analyze and improve the performance of a timing critical application.
Step Two of the code coverage analyzer accepts the name of the log file that was generated in Step One and creates a DBF file of the name supplied.
Figure 2: The Convert Tab of the Code Coverage Analyzer converts the output to a DBF
Step Three reads the table created in Step Two and allows several different types of analysis to be performed on the results. As we'll see in the demonstration, very disparate results can be used to draw some pretty strong conclusions.
Figure 3: Converted to a DBF, it is easy to analyze the resulting information.
Let's review the options available and the priority in which they should be considered:
Always consider Rushmore optimization options as you are designing tables and writing code. A DELETED() tag on every table is a necessity. Tags on every field in a table that gets used in a WHERE or FOR clause ensures optimal performance in nearly all cases. Setting LockScreen True and avoiding unnecessary I/O improves performance dramatically.
Improving the hardware on target platforms can often turn out to be a more economical move than overhauling a system to squeeze out additional performance improvements.
If you suspect or are unsure of the speed of a particular command or piece of code, benchmark it to determine how fast it will be. Remember to take the results with a grain of salt, as FoxPro measurements of time are not accurate and the artificiality of setting up a testing environment can skew the results.
While it is not its primary purpose, code coverage analysis can be used to get some relative benchmarks of code segments, and point to areas needing additional attention.
Ted Roche is the director of development at Blackstone Incorporated, a Microsoft Solution Provider based in Arlington, Massachusetts specializing in database development and network infrastructure using Microsoft BackOffice and Visual Tools. He is co-author, with Tamar Granor, of the critically acclaimed „Hacker’s Guide to Visual FoxPro 3.0“ from Addison-Wesley. Ted is a Contributing Editor for FoxPro Advisor magazine and co-authors the "Ask Advisor" column. He is a Microsoft Certified Solution Developer, a Microsoft Support Most Valuable Professional and a CompuServe Support Partner. Email: tedroche@compuserve.com, phone: (617) 641-0400.
Developer's Guide, Chapter 14, Testing and Debugging Applications - the only documentation on working with code coverage output.
Developer's Guide, Chapter 15, Optimizing Applications - this is a great chapter to read, read again, and bookmark for review for issues on Rushmore optimization and general coding techniques.
"Set Turbo On: How Visual FoxPro Memory Usage Affects Performance," FoxTalk magazine, February 1997
[1] [2]