I was recently performance testing a logging component I’d written which simply logs entries to text file when I stumbled on a performance bottle neck I’d never come accross before.

I wrote the following simple test:

System.Diagnostics.Debug.WriteLine(“Starting 10000 logs entries at: ” + DateTime.Now.TimeOfDay.ToString());

for(int i = 0; i < 10000; i++)

Logger.Instance.CreateLogEntry(“New entry number ” + i.ToString());

System.Diagnostics.Debug.WriteLine(“Finished writing entries at: ” + DateTime.Now.TimeOfDay.ToString());

This managed 10,000 writes in 0.5 secs. I then added the following line into the CreateLogEntry method:

if (_logDate.Date != DateTime.Now.Date)

I was using this check to see if the date had rolled over to the next day (This component is used by a windows serivce that runs continuously and creates a new log file each day). When I re-ran my test imagine my horror to see that the 10,000 writes was now taking 5 mins and 19 secs!

For a moment I wondered how date comparisons in .NET could possible be so slow, and it was then that I realised I was never initialising _logDate, so each time the CreateLogEntry method was called I was doing a comparison between DateTime.Now.Date and null. After fixing my mistake I was back to doing 10,000 writes in 0.53 secs… much better!

It did teach me an important leason though. Comparison with null is very expensive and should be avoided at all costs if performance is a priority.

Well, I’ve been using datasets since I started using .NET about 3.5 years ago, but in the past few days I’ve learnt a few new things that I thought I’d share with you.

Datasets are not stored internally as xml. I guess I had always assumed that they were, probably for a couple of reasons. One; I think someone told me this early in my .NET experience; and Two, datasets handle xml so well it almost seems like a logical conclusion. Suffice it to say, I was wrong, and you can find out all the details here.

Another point of dataset enlightenment I had is this:

Databinder.Eval is bad! Apparently ( and I must admit I haven’t written any tests to prove this, although it does make sense ) using Databinder.Eval is about 20% slower than using explicit casting. This is because Databinder.Eval uses reflection to figure out what the type of the object in the container is that you are trying to display. So instead of doing something like this:

<%# Databinder.Eval(Container.DataItem, “MyItem”) %>

you should do something like this:

<%# ((DataRowView)Container.DataItem)[“MyItem”] %>

however if you do this, you will also need to add this line

<%@ Import Namespace=”System.Data”%>

to the top of your html page , otherwise you will get the following error at runtime:

Compiler Error Message: CS0246: The type or namespace name ‘DataRowView’ could not be found (are you missing a using directive or an assembly reference?

You can find out more about this here.