Share via

Profiling Tips

  • Article

|  How Do I |  Details

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.