Profiling Tips

Home |  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 Visual C++ Editions.

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.