Debug Timing (and a little design pattern, to boot)
In almost every bit of code I write that's actually destined to go into a real system, I find myself start to look for places to optimize code. But having read the writings of Rico Mariani, I am weary of premature optimizations. So what do we do? We measure, of course.
A full-fledged profiler is often overkill when I just want to check how long a method runs. Sometimes a few quick debug-printouts will do the job just fine. I've written hundreds of Debug.WriteLine("Start block") and Debug.WriteLine("End Block") statements, and it get wearisome typing the same commands, formatting the same start and end times, again and again.
So without further ado, he is the complete code for my little DebugTimer helper class, implemented using the Disposable Design Pattern of which I am so fond. Use it in good health.
public
class DebugTimer : IDisposable{
private DateTime start;
private string label;
private static int level = 0;
public static DebugTimer Start (string Label)
{
return new DebugTimer(Label);
}
private DebugTimer (string Label)
{
level++;
this.label = Label;
this.start = DateTime.Now;
string message = string.Format("{2}{0}: {1}", this.label, "Starting", new string(' ', level));
System.Diagnostics.Debug.WriteLine(message);
} public void Dispose()
{
TimeSpan time = DateTime.Now.Subtract(this.start);
string message = string.Format("{2}{0}: {1}", this.label, time.ToString(), new string(' ', level));
System.Diagnostics.Debug.WriteLine(message);
level--;
}
}
EDIT: I forgot to add a little usage sample here. Should be pretty clear, but just to cover all my bases:
public void SomeMethod ()
{
using (DebugTimer.Start("My Code Block"))
{
// Code to time.
}
}
4 Comments
Comments have been disabled for this content.
Dan McKinley said
Very nice idea of taking advantage of using() for this. I guess I would use methods with ConditionalAttribute or #if DEBUG's so that this isn't done in the release code. There are few things more annoying than a third-party component spamming my debugger or trace listener with instrumentation--you'd be surprised how many vendors do this.
Dan McKinley said
Nevermind the diatribe, the Debug class would not emit the messages in Release. I'd still use my own conditionals to avoid the rest of the code, but I'm a little nuts.
Ori Folger said
Classic use of IDisposable.
However, I think stylistically it's better to avoid the static Start method and call the constructor directly.
Your style is hiding from the reader of the code that there is an object being created and then disposed, which is what one expects from a using().
Another good use of IDisposable is for transaction handling. Got any other nice uses for it?
Avner Kashtan said
My original code had it that way, and I changed it purposefully. I figured putting it in a using() block already implies it instantiates an object, and the Start() method is clearer than object instantiation.
As for transactions - this is usually handled in the framework by attributes - a perliminary form of Aspect Oriented Programming. In the Framework 2.0, though, you have a TransactionScope object, which is used in a using() block too.
I've used this pattern for impersonation, as I've linked to. Basically, anything which should have a scoped lifetime can be wrapped in an IDisposable.
UI elements? Hmm.
using (new Cursor(Cursors.Hourglass))
{
}