Building the Right Environment to Support AI, Machine Learning and Deep Learning
In last month's article, "Improve Code Performance with the VSTS Code Profiler," the VSTS profiler was introduced, and simple techniques for finding performance problems in applications where demonstrated. These simple techniques will scale to a relatively large code base, but for very complex applications, which are much more common in the C++ world, diagnosing and fixing performance problems can pose a challenge. In this article, advanced use of the VSTS profiler will be covered, and techniques to quickly and effectively target performance problems will be demonstrated.
Filtering Performance Results
To emphasize one of the key points from the introductory article, one of the simplest and most effective techniques for avoiding collecting excessive amounts of data in a profiling session is avoiding the urge to switch from sampling profiling to instrumentation profiling too early, and minimizing the number of projects that have instrumentation applied. Instrumentation-based profiling collects much more data, and if it is switched on before the specific area of a software system where the performance problem is occurring has been identified with sampling, extremely large profiling files can result.
For large code-bases or performance problems that are intermittent, it is still possible to end up with a large performance result file. One of the advances in the VSTS 2008 profiler is the ability to intelligently filter the results of a performance session. By default, functions that do not call other functions, which are referred to as short functions in the profiler's documentation, are excluded from the results of a profiling session, and the time taken in these functions is charged to their parent functions. For most applications, this is a reasonable default, and small functions will rarely be the cause of excessive performance problems. If a particular profiling target has small functions where it is suspected performance problems may lie, it is possible to change this setting, as shown in Figure 1.
Figure 1: Including Small Function Results for a Profiling Target.
In addition to the small function exclusion feature, which must be set before a profiling session is conducted, the VSTS 2008 Profiler also supports post-profiling simplification of profiling results through a feature known as Noise Reduction. On the Call Tree View (which is one of the most useful views in tracking down performance problems) and the Allocation View, noise reduction presents a clearer picture of the results by excluding functions whose timing or allocation threshold fall below a certain level. Figure 2 shows the Call Tree View with the link to the Noise Reduction screen, and clicking on this link will bring up the Noise Reduction options shown in Figure 3. In the Call Tree View, functions can be trimmed (which removes them from the view) or folded (which combines consecutive functions) that have a certain percentage time threshold, and for Allocations, the thresholds are set based on number of allocation or the number of bytes allocated.
Figure 2: Call Tree View with Noise Reduction Hyperlink.
Figure 3: Configuring Noise Reduction.