Thursday, February 01, 2007

An Introduction to the Coverage Profiler Application

Visual FoxPro (starting in version 7) comes with a built-in tool called the Coverage Profiler Application. This tool is designed to both cover (log information about each line of code run during program execution) and profile (produce useful information about the lines of code that are run) source code. The primary use for this tool is to detect code bottlenecks (which lines of code are taking too long to execute) and to locate lines of code not executed. These two functions of the Coverage Profiler are worth their weight in gold.

Sometimes I get the feeling that software performance is an afterthought during the development cycle. The code must work first. If time permits, then it is customary to go back and fine tune the source for performance. But reality (which many of you are living in) soon sets in, and time just doesn't permit for this type of engineering. Of course, if performance is absolutely horrible then that must be addressed, but a half a second here or a quarter second there isn't going to stir any milkshakes.

But coverage logs can really help. Consider a process (like saving a record) that zips along on a development machine, but crawls on an older test machine built some time before iPods came out. Having some knowledge of the coverage profiler can not only identify the problem, but can also help you solve it. You can identify the trouble spots in the call stack right down to the line of code causing the problem. Each problem you encounter will be different from the last, but identifying the problem will be the same.

The other major benefit of this tool is seeing which lines of code did not run. For testing purposes, this ability can really go a long way in flexing a new function or in testing a 'fixed' bug. It can show you where test cases are falling short, and allow you to write updated scripts that touch each line of code. It will also expose unnecessary blocks of code that an eager developer might have thought necessary (Developers: when was the last time you added an OTHERWISE statement to a DO CASE that you knew would never run? Of course, this practice is a good idea for clarity and readability, but perhaps a comment or ASSERT would be sufficient?).

What's more is that the source code for these tools (coverage and profiler applications) is included with VFP. The Fox Development team has always encouraged its users to modify and enhance these tools to suit individual needs. Unfortunately I have not seen too many enhancements online over the years from other developers. Maybe the core functionality is good enough? I think so. But Perhaps I'll think of something to build and put it here on this blog...


Rick Schummer said...


I agree with the importance of the Coverage Profiler. I use it when I hit some slow code.

Do you know about the add-in capability? There is a new add-in in the Solution Samples that ship with VFP 9 to better analyze the performance. I wrote a similar add-in in MegaFox years ago.

Another key is the Coverage logs can be created in a run-time application starting in VFP 9. The negative is the pathing stored in the log is relative to the production folders. I wrote a path translater in the What's New In Nine book.

Tod McKenna said...

Hi Rick, I've used the add-in capability a few times (while experimenting with the tool a few years ago). I was completely unaware that VFP9 shipped with an add-in in the Solution Samples though! Next chance I get, I'll be taking a look. Thank you for the heads-up!

Andrew MacNeill said...


The other think to look at is Lisa Slater Nichol's stuff on Coverage Profiler. She's written a bunch of add-ins that are very cool including being able to graphically show how code is working.