Pitfalls and Limitations

This section discusses some of the limitations of CGProf and how to accommodate them when creating and analyzing profiles.

The CGProf cycle count profiler uses a hardware time-stamp counter. This makes it possible to record timing information for all activity on the system, including activity in modules (such as the Windows NT kernel) that cannot be instrumented by Etch. Because cycle count profiling measures all activity on the system, it is important to use it on a system with a minimal amount of idle time and background activity. Any background activity that occurs during the profiled run will be miss-attributed to some part of the application. If it is not possible to eliminate background activity, the instruction-count profiler should be used. Similarly, idle time on the system will be attributed to the procedure call that is blocked waiting on completion of an I/O request, making instruction counting preferable for many interactive or I/O bound programs. Of course, if your application is I/O bound, the biggest improvements in application performance will come from reducing the amount of I/O that your application does, and not from profile-directed tuning.

CGProf gets procedure names for instrumented modules from the debugging information that is compiled into the module. If a module is compiled without debugging information, no procedure names will be available. Etch currently supports CodeView versions 9 and 11 format only. Use cl /Z7 /MTd or cl /Zi /MTd and link /debug /pdb:none to produce debugging information for Etch.

In the absence of debugging information, Etch approximates procedure boundaries by identifying the targets of call instructions. This notion of procedure boundaries is an approximation of the true procedure boundaries in the program source code, and tends to break procedures into smaller pieces than occur in the program source. Profiling with accurate procedure boundaries requires debugging information.

CGProf DLL usage reports include all DLL routine references that are imported statically at compile time. For DLL routines imported at runtime using the Win32 call GetProcAddress(), CGProf provides profiling information if the DLL is instrumented. CGProf cannot detect calls to dynamically-imported DLL routines in uninstrumented modules. Time for these calls will be attributed to the calling routine.

Remember that the DLL call profile is available only for cycle count profiles. CGProf has no way of quantifying activity in uninstrumented code, including DLL routines, when generating an instruction count profile.