Profiling Tips
Feature Only in Professional and Enterprise Editions Profiling is supported only in Visual C++ Professional and Enterprise Editions. For more information, see .
This section discusses some guidelines for approaching your profiling task.
Don't profile your entire application. Profile only the specific areas of interest to you. See PREP Phase I commands /EXC and /INC. There are a lot of areas that don't make sense to profile. For example, you probably don’t care about performance in general user interface code.
Reported times will be inaccurate, so do an average of a few runs and keep accurate notes. The averages will be more precise. You can accumulate profiler statistics for multiple runs by merging (the Merge option).
To get more consistent results, reduce the number of processes running on your machine when you profile.
Disconnect any network connections to relieve the operating system of the need to service incoming packets.
If you are profiling with function timing and your timings and calculated overhead vary, you may want to use the /CB switch in PREP Phase I. Calculated overhead appears in default (not tab-delimited) PLIST format.
Analyze the report. If you have a function that is reportedly using a lot of time, see if the reported calls to profiled subroutines add up to roughly the amount of time the function is using.
Look at the hit counts. If you are iterating through an algorithm 1,000 times, are the functions it uses getting called the right number of times? Is there a way to reduce the calls? If a function isn't used, it doesn't cost anything.
Just because you have a tried and true function, don't discount it as a possible problem.
The times attributed to a function also include any children of the function.
Disk caching can result in faster subsequent profile runs.
Linked lists are slow; profiling shows this.
Long functions can be difficult to profile. In some cases you may want to wrap part of a function within a subroutine to check the timing of that chunk of code.
You can't profile threads. You can, however, use the /SF PREP (phase I) option to start profiling at the function that is the thread entry point. Or, to test a thread, make it a subroutine and create a special test case for it; this can be difficult to do.
For tips on how to improve your code to increase performance, see Tips for Improving Time-Critical Code.