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 ArrayList.

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 Compare method).

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 Compare method.

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.

The biggest thing missing from 1.1 is the ability to exclude time spent inside calls that block (e.g. Monitor.Wait(), file and network i/o that block) . This makes it difficult to use for high performance applications that do a lot of i/o or have a lot of threads.

I requested this feature in the past and I never really got a good response.

Brien,
That’s right, dotTrace currently measures “wall time” – time which was actually spent during function call even if the thread was blocked part of the time. Often it is useful: you want to know that a substantial amount of time was spent waiting for a resource. But sometimes knowing how much time was spend doing real work is also neccessary. Unfortunately just excluding known blocking functions doesn’t solve the problem because some blockers are not represented by a managed call.

I tried out the trail for the 1.1 version of DotTrace, but compared to Redgate’s Ants Profiler that I use on a day-to-day bases, it adds much more overhead than Ants Profiler. So, when I’m profiling a slow method, it will be cost like 1.5 times more time in Ants and 2.5 times more in DotTrace.

Also, I found the interface of the Ants Profiler much more clear. But maybe that’s because I’m not very familliar with DotTrace. Anyway, I had a hard time locating for example the top 10 of slowest lines of code, slowest methods with children etc. Also, in Ants I can see the callers from and to a method, I could not find it how to do this in DotTrace.

It’s interesting that you notice more overhead from dotTrace than from Ants profiler. Our measurements show that dotTrace implies ten times as little overhead than Ants does. Which applications do you profile? Regarding the interface: finding out the slowest functions is one click away: just open the Hotspots view. It displays 50 slowest functions and by which call stacks they were called. To investigate a particular function just open it in a separate tab (by pressing Control+T). In this tab you can use Call Tree view to see which functions the current function calls and Backtraces view to see who calls the current function. Hope this helps. If you have other questions you can ask them in the newsgroup or contact me directly at oleg.stepanov (at) jetbrains.com.

Thank you for you clarification. I’m not certain what the exact conditions where when I noticed the extra overhead, but I recall it was in a situation with multi-threading with a huge amount of small function calls. Good to hear that in most situations dotTrace has much lower overhead! Next time I need to do profiling, I’ll try out the EAP.

I have worked with Ants profiler and after evaluating your product I have requested a refund because of few reasons:
1. It has many problems profiling 2.0 ASP.NET application while there are 2 frameworks working (dev team told me to request a refund)…
2. The performance penalty that i paid with ants is enormous.

* One thing missing is the ability to see the performance of each line (not only functions)!