dotTrace Profiler 2.0 further improves performance profiling
First, just a few opening words for our first post about dotTrace Profiler. The currently released dotTrace Profiler (Version 1.1.2) offers convenient and robust performance profiling of .NET Framework 1.1 and 2.0 applications, including ASP.NET applications. What is more interesting, though, is that dotTrace 2.0 is in the works and it’s going to include memory profiling, snapshot comparisons, integration with Visual Studio, and many other cool features. Tune in to our .NET Tools blog to keep up-to-date with its latest developments! You are also welcome to visit the dotTrace Early Access Program for a working preview of version 2.0.
While the major feature added in dotTrace 2.0 is memory profiling, we havenâ€™t abandoned improving the performance part. Here we dip into one of the new features added in this area: collapsing filtered calls. In general, this feature helps you quickly estimate how much time was spent on complex call trees.
For example, letâ€™s take a look at a CPU snapshot from dotTrace which displays profiling data for the code sorting of an
It clearly shows that a single call to
ArrayList.Sort method generates a pretty complex call tree (according to QuickSort algorithm) at the points where our comparer is called. So, we see a long list of
Compare method calls (click the image to open the full screenshot). The problem here is that we would like to know how much time in total the comparison took (or just sum up time for all of the calls to the
As it stands now, in dotTrace 1.x you can open the call in a separate tab, then go to Plain View and see the statistics for the
Well, with dotTrace 2.0 things get much simpler. See the small icon at the line for
Sort method call (the highlighted line on the screenshot above)? It appears for topmost filtered nodes and is used to collapse all filtered calls underneath it into a single node. If you click the icon on the snapshot, the view is transformed into the following:
Now the entire tree of underlying dynamics of QuickSort has been transformed into a single node under which all calls to the
Compare method are placed. As a result, it’s is now much easier to understand how much time was spent on comparing elements.