This post dives into IntelliTrace Events as available in Visual Studio 2010 Ultimate edition, explaining what they are, how they work and the benefits to be had.
The typical “F5” usage pattern of IntelliTrace goes something like this:
- Press F5 while in Visual Studio to initiate a debug run
- Record an IntelliTrace session of your application during execution
- Use the recorded information to enable replay of the execution
- Analyze the data to determine what happened
Let’s take a look at some really useful analysis that can be done with IntelliTrace event information.
The examples in this post will assume the default settings for IntelliTrace that configure the feature to only record selected “IntelliTrace events”.
You can think of these events like log entries that are handled for you without adding anything to your code at design time. You can turn on or off event collection by category or by individual events within a category. The only event type that you do not have control over are Exceptions. Regardless of any other events that may be selected IntelliTrace will always capture Exceptions thrown and caught when IntelliTrace is enabled.
What can be prove to be an interesting exercise is to take a look at the events list that IntelliTrace captures during a run of your application. Do this by checking that IntelliTrace collection is enabled as shown in the first screenshot and then run your application in Visual Studio in debug mode. Walk through a usage scenario or two in your application. Before exiting your application return to Visual Studio and select the “Break All” link in the IntelliTrace window.
If you don’t see the IntelliTrace window, open it by going to Debug -> IntelliTrace -> IntelliTrace Events from the Visual Studio menu or by pressing Ctrl+D, V. What you see next depends on what events IntelliTrace collected during the execution of your application. You may see anything from a very short list to a very long list. The events are listed in the chronological order in which they occurred with the first event at the top and the last event at the bottom of the list.
Reviewing the events list can provide insightful information about the behavior of your application, the structure of the code, various IO performed and many other things. Take a look at the following events list as taken from a quick usage of the StockTrader sample WCF application:
By reviewing this events list you can determine which database calls were made, what requests were made to the web server, what exceptions were thrown and caught and any breakpoints that were hit. Analyzing this information can be very beneficial as part of a code review as well as provide understanding of execution paths and opportunities for improvement in addition to finding and resolving bugs.
Click any of the events in the list to get further information. For example, clicking on the first exception may do a couple of things.
- it expands the event to provide more information inline as shown below.
- If you have the solution open in Visual Studio that contains the point where the exception was thrown it will take you to the code
- Your application execution is “rewound” to the point where the exception was thrown for further analysis
At this point you can review the call stack by clicking the “Call Stack” link, which will open the call stack window.
Expanding one of the ADO.NET events in the list provides both the query that was executed as well as the connection string that was used.
This can be especially valuable when trying to track down connection permissions issues or query problems. A huge benefit that many people have discovered is when you are using data access technologies like Entity Framework or Linq to SQL as this event will show you the SQL statement that was generated and executed based on your LINQ statements. Very handy!
People are often surprised when they examine the ADO.NET statements in the list of events. Frequently it is discovered that there are far more database calls being made than expected. The events list can also present duplicate calls that are executed. This can be a great opportunity to investigate caching strategies.
So how is this event collection done?
Each event in the events list is associated with some method in the .NET framework. When you execute your application within Visual Studio these methods have additional code injected that writes the data that you see in the events list to an IntelliTrace log. The impact to execution is completely dependent on how often the methods that have the additional instrumentation are executed. If you find that IntelliTrace is slowing down the execution of your application and you have only events collection enabled (see the first screenshot) take a look at the events list, you may discover that one or more events are being recorded many times. This may indicate redundant execution within a loop perhaps. For example if you have a loop that executes 1000 times and, unknowingly, each iteration performs a database query or a registry lookup you will find that IntelliTrace collection of that many events will impact performance. The benefit of all of this is that you will have discovered a great opportunity to refine your code and reduce potentially redundant code execution!
Hopefully you will see how IntelliTrace events alone can provide great value to your development cycle. There is a lot of valuable information to be mined from them. Take a look at the events that are available and turn on the ones that your code would encounter during execution. Take some time to examine how your code works and maybe you will find opportunities for improvement as well as fix your bugs faster.
I am always eager to hear about your experiences using IntelliTrace!
0 comments:
Post a Comment