Pitfalls and Limitations

This section discusses some of the limitations of the Etch Call Graph Profiler and how to accommodate them when creating and analyzing profiles.

The Etch Call Graph 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 erroneously attributed to some part of the application. Idle time on the system will be attributed to the procedure call that is blocked. Of course, if your application is I/O bound, the biggest improvements in application performance will come from reducing the amount of I/O required by your application. A future release of the Etch Call Graph Profiler may provide instruction count profiles.

The Etch Call Graph Profiler 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 debug information in CodeView version 9 and 11 formats only. With MSVC, use cl /Z7 /MTd or cl /Zi /MTd and link /debug /pdb:none to produce debugging information for Etch. For other compilers, consult the documentation provided with the compiler.

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 may occur in the program source. Profiling with accurate procedure boundaries requires debugging information.

The Etch Call Graph Profiler cannot detect calls to dynamically-imported DLL routines in uninstrumented modules. Time for these calls will be generally be attributed to the calling routine.