I thought of writing a post on profiling the SharePoint code using DebugView tool. Because DebugView is bit undermined and it’s not widely used for profiling SharePoint code. You can think of leveraging DebugView tool, when you can’t do a remote debugging and when the Developer Dashboard does not give you much information. DebugView comes handy in such scenarios and it is also less invasive approach of profiling the code.
The whole idea is to place set of Debug statements in your code and run the DebugView tool on the server. Then DebugView tool captures all the output from Debug statements and lists them.
I’ve an event handler by name ‘TestListEventHandler’ attached to a custom list called ‘TestCustomList’
Now I’ll be adding the Debug statements (System.Diagnostics.Debug.WriteLine) to the event handler methods.
My event handler implementation looks like the following with Debug statements.
public override void ItemAdding(SPItemEventProperties properties)
{
System.Diagnostics.Debug.WriteLine("Entering Item Adding Event");
base.ItemAdding(properties);
System.Diagnostics.Debug.WriteLine("Exiting Item Adding Event");
}
/// <summary>
/// An item is being updated.
/// </summary>
public override void ItemUpdating(SPItemEventProperties properties)
{
System.Diagnostics.Debug.WriteLine("Entering Item updating Event");
base.ItemUpdating(properties);
System.Diagnostics.Debug.WriteLine("Exiting Item updating Event");
}
/// <summary>
/// An item is being deleted.
/// </summary>
public override void ItemDeleting(SPItemEventProperties properties)
{
System.Diagnostics.Debug.WriteLine("Entering Item deleting Event");
base.ItemDeleting(properties);
System.Diagnostics.Debug.WriteLine("Exiting item deleting Event");
}
/// <summary>
/// An item is being checked in.
/// </summary>
public override void ItemCheckingIn(SPItemEventProperties properties)
{
System.Diagnostics.Debug.WriteLine("Entering Item checingin Event");
base.ItemCheckingIn(properties);
System.Diagnostics.Debug.WriteLine("Exiting Item checking-in Event");
}
/// <summary>
/// An item is being checked out.
/// </summary>
public override void ItemCheckingOut(SPItemEventProperties properties)
{
System.Diagnostics.Debug.WriteLine("Entering Item checking out Event");
base.ItemCheckingOut(properties);
System.Diagnostics.Debug.WriteLine("Exiting Item checking out");
}
/// <summary>
/// An item is being unchecked out.
/// </summary>
public override void ItemUncheckingOut(SPItemEventProperties properties)
{
System.Diagnostics.Debug.WriteLine("Entering Item unchecking out Event");
base.ItemUncheckingOut(properties);
System.Diagnostics.Debug.WriteLine("Exiting Item checking out");
}
/// <summary>
/// An attachment is being added to the item.
/// </summary>
public override void ItemAttachmentAdding(SPItemEventProperties properties)
{
System.Diagnostics.Debug.WriteLine("Entering Item attachment Adding Event");
base.ItemAttachmentAdding(properties);
System.Diagnostics.Debug.WriteLine("Exiting Item attachment Adding Event");
}
/// <summary>
/// An attachment is being removed from the item.
/// </summary>
public override void ItemAttachmentDeleting(SPItemEventProperties properties)
{
System.Diagnostics.Debug.WriteLine("Entering Item attachment deleting");
base.ItemAttachmentDeleting(properties);
System.Diagnostics.Debug.WriteLine("Exiting Item attachment deleting Event");
}
/// <summary>
/// A file is being moved.
/// </summary>
public override void ItemFileMoving(SPItemEventProperties properties)
{
System.Diagnostics.Debug.WriteLine("Entering Item file moving Event");
base.ItemFileMoving(properties);
System.Diagnostics.Debug.WriteLine("Exiting Item file moving Event");
}
/// <summary>
/// An item was added.
/// </summary>
public override void ItemAdded(SPItemEventProperties properties)
{
System.Diagnostics.Debug.WriteLine("Entering Item Added Event");
base.ItemAdded(properties);
System.Diagnostics.Debug.WriteLine("Exiting Item Added Event");
}
Now I’ll be running the DebugView tooll with the following capture settings
DebI’ll start adding an item item to the custom list.
DebugView captures the debug statement emitted from the code like the following.
We can measure execution test time of a particular method/statement by placing them within a enclosed Debug statements (like mentioned in the above code snippet). The tool would give you exact time (in milliseconds) when the particular debug statement is executed. If we can compute the difference in time reported between two debug statements, that would give us an exact time it takes to complete a task (a statement or a method or an external call).
The other advantage of debug view is that we can figure out the execution path of our code at runtime, like how many times a method is called or has a method been skipped etc. The log produced by DebugView can also be exported into a separate file.
Pingback: Profiling SharePoint code using DebugView tool - My experiments with SharePoint, Azure and .NET using Visual Studio
Useful information