Miscellaneous Debris

Avner Kashtan's Frustrations and Exultations
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.
   }
}

Published Wednesday, September 28, 2005 8:40 PM by AvnerK

Filed under: ,

Comments

# re: Debug Timing (and a little design pattern, to boot)@ Wednesday, September 28, 2005 9:57 PM

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

# re: Debug Timing (and a little design pattern, to boot)@ Wednesday, September 28, 2005 9:59 PM

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.

Dan McKinley

# re: Debug Timing (and a little design pattern, to boot)@ Thursday, September 29, 2005 5:36 AM

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?

Ori Folger

# re: Debug Timing (and a little design pattern, to boot)@ Thursday, September 29, 2005 6:46 AM

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))
{
}

Avner Kashtan

# re: Debug Timing (and a little design pattern, to boot)@ Thursday, September 29, 2005 9:43 AM

Dan: The Debug.WriteLine() calls aren't executed in Release builds, and in Debug builds are accessible even if we don't have a debugger attached to the process - using tools like SysInternals' DebugView tool - http://www.sysinternals.com/Utilities/DebugView.html

Avner Kashtan

Leave a Comment

(required) 
(required) 
(optional)
(required)