March 26, 2008

.NET Code Performance Measurement

When improving the performance of your code, it's often usefull to know how fast (or slow) your code is running. I was going to show you a neat little class that I've been using for years that wraps some Win32 API functions, but my pre-blogging research has revealed that my approach is a bit outdated. Since .NET 2.0 there has been just such a wrapper class baked into the framework. It's the System.Diagnostics.Stopwatch class. It's use is simple:


Stopwatch timer = new Stopwatch();
timer.Start();

...Code to evaluate goes here...

timer.Stop();
double elapsed = timer.ElapsedMilliseconds;

In addition to getting the ElapsedMilliseconds, you can also access the Elapsed property to get a timespan or ElapsedTicks to get the ticks.

November 26, 2007

ICustomTypeDescriptor

Recently I had what is probably a very strange need, but I doubt I'm the first one to have it. I essentially had a two dimensional array, more specifically an object of type List<Dictionary<string,string>>, that I needed to bind to a GridView. I couldn't use a custom collection because the schema of the data structure could be just about anything (the GridView columns were being built at runtime). I won't get into the details of why I was using a List of Dictionary objects as opposed to simply using a DataTable, but for the sake of simplicity let's just say it was the only option I had. Now what I needed to do with this collection was to bind it to the GridView, using the keys in the Dictionary as the DataField for the columns.

My first thought..."maybe it'll just work". I knew I was being overly optimistic, but I had to try anyway, and I received an error message of "'KeyName' is not a member of Dictionary", or something to that effect. Now I knew that the ability to bind to a dynamic schema based on column names existed in the DataTable, so I opened up Reflector and took a peek under the hood. After a few minutes of rummaging around I came across the golden treasure that is ICustomTypeDescriptor.

If you were to think of a custom class as a spy for some reason, then ICustomTypeDescriptor would be like a disguise that allows your object to masquarade behind enemy lines pretending to be something it's not (I've been playing a lot of Team Fortress 2 lately). On a more technical level, any time your object is accessed via reflection, in databinding for example, ICustomTypeDescriptor allows you to define the facade that your object exposes at runtime. So let's say I have a column in a GridView that is bound to the "ID" property of my custom object. If my object doesn't have an "ID" property then we get an error, but if my object implements ICustomTypeDescriptor then I can trick the calling code into thinking it has a property called "ID", and whenever the value of that property is requested my object can run whatever custom logic I write in order to return a valid value.

Let's get to the code. We need to start by abstracting that generic dictionary into a custom class that we can slap ICustomTypeDescriptor on. Here's what the end result looks like:

public class MyCustomClass : Dictionary<string, string>, ICustomTypeDescriptor
{
private PropertyDescriptorCollection m_PropertyDescriptorCollectionCache;

AttributeCollection ICustomTypeDescriptor.GetAttributes()
{
return new AttributeCollection(null);
}

string ICustomTypeDescriptor.GetClassName()
{
return null;
}

string ICustomTypeDescriptor.GetComponentName()
{
return null;
}

TypeConverter ICustomTypeDescriptor.GetConverter()
{
return null;
}

EventDescriptor ICustomTypeDescriptor.GetDefaultEvent()
{
return null;
}

PropertyDescriptor ICustomTypeDescriptor.GetDefaultProperty()
{
return null;
}

object ICustomTypeDescriptor.GetEditor(Type editorBaseType)
{
return null;
}

EventDescriptorCollection ICustomTypeDescriptor.GetEvents(Attribute[] attributes)
{
return new EventDescriptorCollection(null);
}

EventDescriptorCollection ICustomTypeDescriptor.GetEvents()
{
return new EventDescriptorCollection(null);
}

PropertyDescriptorCollection ICustomTypeDescriptor.GetProperties(Attribute[] attributes)
{
if (m_PropertyDescriptorCollectionCache == null)
{
PropertyDescriptor[] properties = new PropertyDescriptor[this.Count];
int i = 0;
foreach (string key in this.Keys)
{
properties[i] = new MyCustomClassPropertyDescriptor(key);
i++;
}
m_PropertyDescriptorCollectionCache = new PropertyDescriptorCollection(properties);
}
return m_PropertyDescriptorCollectionCache;
}

PropertyDescriptorCollection ICustomTypeDescriptor.GetProperties()
{
return ((ICustomTypeDescriptor)this).GetProperties(null);
}

object ICustomTypeDescriptor.GetPropertyOwner(PropertyDescriptor pd)
{
return this;
}
}

Mostly it's a lot of methods that I didn't need for the purpose of databinding, so I just return null. The heart of the whole thing is the GetProperties method. Note that it is overloaded in the interface to allow for filtering by certain attribute types. I didn't have a need for this so I didn't write the code to do it, but you're welcomed to if you like. Anyway, the purpose of this method is to return a PropertyDescriptorCollection that describes all of the properties of the object. In my case I needed to expose every key in the Dictionary as a property that I could bind to, so that's what it does.

Now if you're paying attention you'll notice that it's slightly more complicated than that. We also have to create another class that contains the logic to retrieve a value from the dictionary when a property is requested:

public class MyCustomClassPropertyDescriptor : PropertyDescriptor
{
public ResponsePropertyDescriptor(string key) : base(key, null)
{

}

public override bool CanResetValue(object component)
{
return true;
}

public override Type ComponentType
{
get { return typeof(Dictionary<string, string>); }
}

public override object GetValue(object component)
{
return ((Dictionary<string, string>)component)[base.Name];
}

public override bool IsReadOnly
{
get { return false; }
}

public override Type PropertyType
{
get { return typeof(string); String.IsNullOrEmpty(string value); }
}

public override void ResetValue(object component)
{
((Dictionary<string, string>)component)[base.Name] = string.Empty;
}

public override void SetValue(object component, object value)
{
((Dictionary<string, string>)component)[base.Name] = value.ToString();
}

public override bool ShouldSerializeValue(object component)
{
return false;
}
}

This is a pretty simple class that inherits from PropertyDescriptor. When we instantiate it we pass the value of the Dictionary key, which becomes the name of the fake property we are exposing.

So our problem is solved. As the GridView is being bound, it makes a request for the property of MyCustomClass definded in the DataField. Even though that property doesn't actually exist in MyCustomClass, because we have implemented ICustomTypeDescriptor everything is ok. The request gets passed on to the GetValue method of MyCustomClassPropertyDescriptor, which uses the requested property name to retrieve the value from the Dictionary object by key. Very simple and very cool.

June 20, 2007

TouchPoint!

So I've been working on a product for about a year now, and it's finally released. Of course to me it will never be finished, there are always bugs to fix and features to add, but this is still a tremendous milestone. A recent post at Joel on Software hits rather close to home right now.

I'm extremely excited and also extremely nervous. Whenever we turn something we've worked long and hard on over for public scrutiny, certain thoughts are bound to creep in. "Is it good enough? Will it be successful? Have I wasted a year of my life? " I ask myself these questions constantly.

I don't think anything I produce will ever be truly good enough for me, and I mean that in a good way. As a developer I feel that there is always room for improvement and the day I think I'm good enough to stop improving is they day I should stop being a developer. As to my other ponderings of self doubt, no matter what comes of my work I remain extremely proud of it. My skills have improved drastically while working on this product, and I can't think of a better way to spend a year than getting paid to work on something you love.

So take a look at TouchPoint. I think it's pretty cool and hopefully people will find it useful. There are still lots of enhancements and improvements in the works, so keep your eye on it as things develop.

This may seem a bit strange given that the product is commercial, but I'd like to close by giving props to similar products out there that have given us inspiration. I'm proud to be joining their ranks and hope that TouchPoint can live up to the standards they have set:

April 10, 2007

Enterprise Library 3.0 Released

Check it out. Cool new features, and best of all...no breaking changes!!

February 22, 2007

Reflector 5.0 Released

Lutz Roeder's Reflector is by far the most useful development tool I have, besides Visual Studio of course. Often times it gives me what I need to know faster and more accurately than MSDN. So much love goes out to Lutz for such a great contribution. There are several super cool things in the new version.


Scott Hanselman has a nice post explaining some of the new features in greater detail than I care to if you like. Or you can just go get it already:


January 19, 2007

Prototype News!

Prototype, in case you don't know, is a fantastic javascript library that lays the foundation for all the hottest new UI trends on the web. I've been using it for over a year now and I have to say it may just be the greatest thing ever to happen to javascript.

Anyway...they've finally come out with a 1.5 release version. Oh, and they also have a shiny new website with official documentation...that last part just makes me feel all warm inside.

January 3, 2007

Be Judged...And Like It!

I recently ran across a fantastic way to waste some time in a completely productive manner. The Sphere Online Judge works like this:

  1. You choose from a wide array of problems (think back to your computer science classes)

  2. You develop and upload a solution in the language of your choice

  3. Your code is run and judged against the time and memory constraints of the problem

  4. If you pass, you get a warm fuzzy feeling inside. If you fail, you get angry and vow upon the graves of your forefathers to spend every waking moment figuring out how to find all the prime numbers between two given numbers up to 1 billion in under 6 seconds...not that anything like that happened to me.


I think this is a great way to keep your programming skills sharp and have some fun too.