Interesting IntelliTrace Anecdotes

Over the past few months I have had the opportunity to encounter some interesting anecdotes from customers that are using IntelliTrace as part of their development cycle with Visual Studio Ultimate. The ones that I want to highlight here have come to me as perceived flaws with IntelliTrace.  Now don't get me wrong I'm not saying that the feature is flaw free but there are some interesting side effects of using IntelliTrace as part of your development cycle.

IntelliTrace is broken, it's recording way too many ADO.NET calls!
This was an interesting complaint that I got a while back.  A developer was working on an application and looked at the recorded ADO.NET events that we had on the IntelliTrace list and noticed that there were four events listed for the exact same database call. This was not good! We took a look at the problem and it turned out that the path through the application was actually executing the same database call four times.  Naturally IntelliTrace recorded each call.  This was a great example of how IntelliTrace can be used in a static analysis manner on top of runtime data.  We were able to identify a great opportunity to optimize the code and reduce the extra database calls from the code path and make the application faster.

When I turn IntelliTrace on High (IntelliTrace Events and Call Information) it's too slow!
Well this can easily be very true and unfortunately it's one of those things that really depends on a few variables.  Let me explain.  When IntelliTrace is turned on high all of the modules (aka assemblies) are instrumented when you start debugging.  This means that we add extra code to record a certain degree of data for all of the parameters and return values for every single method call in all modules that are not in the inclusion/exclusion list.  Running against the RAWR application using the default IntelliTrace high settings can be a painful experience, however once you have clicked two buttons and patiently waited for the action to complete if you analyze the IntelliTrace data you might find that at least one method was call about 1,250,000 times!  This was occurred when simply clicking two buttons after starting the application!  Of course things are slow when we record data for 1.2 million method calls. This is another great indication that there are some optimization that can be made in the code. IntelliTrace runs slow when it's recording a lot of data.  Take this as a clue to analyze what's going on to seek out opportunities to improve your application.

One of the optimization that was taken early was to turn off certain IntelliTrace events by default.  We did this to improve performance.  During early testing we encountered an application that was running very slowly with IntelliTrace due to a huge number of registry access calls that it was performing. With the registry events turned on data was being collected for each access and it caused poor performance.  What it also did was highlight a tight loop within the code that was accessing the registry far more than was necessary. By moving the call to the same registry out of the loop improved both IntelliTrace performance as well as the application performance.

The default settings for IntelliTrace is to exclude certain modules when running on high mode.  A more optimized approach is to use an inclusion list rather than an exclusion list for the modules. By switching the Modules setting to "Collect data from only the following modules" and then providing strings to match only the modules that you care about will improve performance as well. Otherwise any modules that don't match the exclusion list will be included, this would include all third party modules that you may not care about.

When my boss saw the IntelliTrace log he made me change my code!
Using an IntelliTrace run as part of a code review is a great way to get some insight into what's going on from a high level. Reviewing exceptions that were caught within the user developed code showed a high number of catches that weren't being recorded or rethrown.  Essentially there were exceptions being caught and swallowed.  This is always a danger.  If an exception is thrown and caught but not logged there can easily be bugs in your code that can be very hard to track down.  Reviewing the exceptions data can help you develop more robust applications.

Conclusions
These are a few examples of anecdotes that I have encountered over the past few months that have shown some of the additional value that IntelliTrace adds to the development cycle in addition to the ability to historical debugging.  I hope you find these ideas valuable and can share a few of your own.