Archive for the ‘Performance’ Category

Casting Performance

Tuesday, May 12th, 2009

The system that I am currently working on depends a lot on casting an object to an interface to see if it implements that interface.  If it does, the system will take one action, if not, it will take a different action.  Because of this, casting performance is very important to the overall performance of the software.

As far as I am aware, there are 4 ways in C# to test if a given instance of an object implements an interface (without knowing the exact type of the instance).

1. “as” cast after an “is” check:

if (castingObject is StringBuilder)
{
  StringBuilder testBuilder = castingObject as StringBuilder;
  // do stuff
}
else
{
  // do other stuff
}

2. “as” cast with a null check:

StringBuilder testBuilder = castingObject as StringBuilder;
if (null != testBuilder)
{
  // Do stuff 
}
else
{
  // Do other stuff
}

3. Explicit cast after an “is” check:

if (castingObject is StringBuilder)
{
  StringBuilder testBuilder = (StringBuilder)castingObject;
  // Do Stuff
}
else
{
  // Do Other Stuff
}

4. Explicit cast with InvalidCastException:

try
{
  StringBuilder testBuilder = (StringBuilder)castingObject;
  // Do Stuff
}
catch(InvalidCastException)
{
  // Do other stuff.
}

Method #4 should clearly be the worst performing option if you expect any number of the casts to fail (since throwing an exception is very expensive in .NET).  So which of the three remaining methods would result in the best performance?  Well, the only way to know for sure is to measure it, so that’s what I did.

As Cast with Is check: 0.0082533 seconds.

As Cast with Null check: 0.0077226 seconds.

Explicit Cast with Is check: 0.008119 seconds.

Explicit Cast with No check: 448.7026034 seconds.

Judging from these results, doing an “as” cast followed by a null check is the fastest way to test if an object instance is of a certain type.  Of course, there is not enough of a difference between any of the first three methods to make me redo any existing code, and I certainly wouldn’t sacrifice readability/maintainability just to grab 5 milliseconds or so over 200,000 casts.

If you are curious I ran the casts inside a 100,000 iteration loop, with one “successful” cast and one “failed” cast, for a 50% success rate.  A more clever test would take into account the actual expected failure rate of the casts and use that to measure the performance, but this was just a question of curiosity for me – as I mentioned the possible improvements are too small for me to worry about as long as I avoid the explicit cast with no checks.

Tracking Performance

Thursday, March 5th, 2009

I spend a decent amount of time doing performance testing and improvements.? I work with a lot of “speed critical” code (everything is relative of course).? In my case we are looking at trying to get an execution time of minutes as opposed to hours, so this is not micro-optimization – this is big stuff, algorithms, design changes and so forth.? I have always kept a little PerformanceTimer class buried around in my bag of tricks that simply tracks the number of ticks since the timer was started.? I eventually upgraded it to track intervals so I could start and stop it and track the total time elapsed across all intervals.? Accuracy was never a big push for me – as I mentioned, I am more concerned with large improvements, not a couple of milliseconds here or there (don’t get me wrong, those improvements have their place, they just aren’t my problem).

I have used essentially the same timer class since I first learning C++.? I translated it over to C# when I moved to the .NET platform, and never really looked for alternatives.? About a year or so ago, I decided to see what else was available to see if there was a more accurate way to keep track of this.? Sure enough, starting with v2.0 of the .NET Framework, Microsoft provided a nifty little Stopwatch class.? It certainly did the trick, and since it was included in the framework, I wouldn’t have to keep moving my PerformanceTimer class to each new project I started.

Of course, when I was looking at MSDN today to try to determine exactly what resolution I could get out of the class (just curious – as I mentioned the resolution is far better than what I actually need), I noticed a comment at the bottom of the page claiming that the class was unreliable for multi-processor computers.

So I must admit, I have never noticed any issues using the class.? Of course, I am not nearly as concerned with the actual numbers it gives me as I am with comparing possible optimizations.? The entry is interesting, but is short on specifics.? I looked through to try to determine what the actual unreliability was, but it dug down into specifics that I wasn’t familiar with, leaving me with a lot more to investigate and analyze.

I don’t know if anyone else has encountered any issue with Stopwatch before, but I imagine that if you are timing items down to the millisecond range you should probably be aware of this possible problem.? Of course, you should also probably be aware of the inherent problems with timing to that resolution anyway.

Personally, I’ll keep using the Stopwatch, but it has peaked my interest and I may embark on a more in-depth investigation to attempt to understand the problem.? I can always dust off the old PerformanceTimer class if I need to…