Profiling with Visual Studio Performance Tool

After presenting Valgrind as an emulation profiler, I will present Microsoft solution, Visual Studio Performance Tool. It is available in the Team Suite editions, and offers a sampling- and an instrumentation-based profiler. Of course, it is embedded in Visual Studio IDE and accessible from a solution.

Using the profiler

First of all, the code must be compiled with /Zi or /Z7. Then, the link edition must be done with /DEBUG. Without these options, it won’t be possible to measure anything.

Performance Tool must be used in a Visual Studio Solution, which I don’t have in the case of the Interactive Raytracer. I will have to create an empty project, and I will create a bogus project, just to be able to browse the code in the IDE.

Once in Performance Tool, I create a new target which will be my generated library:

Adding a new target to a Performance session

Then, I have to add it to the targets to profile:

Selected targets to profile

Then I modify the launch properties to launch python with a sample script that is supposed to be descriptive enough. If you profile a Visual Studio project, you can use the debugging project properties (there are more environment parameters that you may modify).

Modify launch properties


To use the sampling profiler, you have to select it in the session parameters. Once done, you can launch the profiler.

This is the results I got from the IRT:

Sampling: Main result page

Only the most relevant are shown in the first panel. The first table is the most important inclusive function. The cost of a function is its cost as well as the functions it has called. Then the second table is the most important exclusive functions: only the cost of the function, without the cost of the called functions, is used.

This view helps finding the function to optimize. It display the current function at the middle of the panel, and then the caller functions at the top and the callee/called functions at the bottom. The displayed costs are inclusive and exclusive costs.

Sampling: Function callers and callees

A more general view, the call-tree, can help finding the hotspot as well. The caller can obviously not be displayed.

Sampling: Call-tree

It is easy to get access to the code by a left click, which is one of the reasons I’ve created a bigus Visual Studio project.


Instrumentation-based profiling is somewhat different than sampling-based profiling. Here, the executable is modified to count cycles or counters, whereas in sampling-based profile, the program is sampled at regular intervals to get where the program is, the counters, …

Instrumentation results are quite like the sampling ones

Instrumentation: Main result page

Instrumentation: Callers and callees

Instrumentation: Call-tree


According to the different results I got, I know that I have some work to do on the math library. Well, this was some months ago, so now this code optimized as well. Based on Performance Tool profile, a lot has been optimized, as not creating rays inside the loop, …

I cannot really compare Performance Tool to Valgrind, as they are not the same kind of profilers. They each give more or less precise information on some parts of your program.
Compared to KCacheGrind, the callee map is missing, but Microsoft did a great job with the UI. The information may not be visualized as a 2D image, but it is still easy to extract it from the different views.

As a conclusion, I’d simply say that Performance Tool is an excellent tool Mixrosoft provides in its high-end Visual Studio versions. To bad it is not acceissble in the lower versions.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.