Question

Recently I had one strange performance problem.
I need to compare time intervals in cycle with large amount of iterations.
I used DateTime.TimeOfDay property to compare these intervals. However, I found that these comparisons are very slow versus DateTime comparisons. So, I had to create DateTime’s with 1 year 1 month and 1 day to speed up time’ intervals comparison’s.
I prepared a small example to show what I mean.

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace DatesBenchmark
{
    class Program
    {
        static void Main(string[] args)
        {
            Stopwatch sw = new Stopwatch();
            sw.Start();
            DateTime firstDate = DateTime.Now;
            DateTime secondDate = DateTime.Now.AddSeconds(5);
            for (int i = 0; i < 2000000; i++)
            {
                var a = firstDate.TimeOfDay > secondDate.TimeOfDay;
                //var a = firstDate > secondDate;
            }
            sw.Stop();
            Console.WriteLine(sw.ElapsedMilliseconds);
            Console.ReadKey();
        }
    }
}

I got 15ms (if first row in for cycle is commented) versus 176 ms (if second row in for cycle is commented) on my laptop.

My question is short. Why?

Answer 1

Calling foo.TimeOfDay is doing this:

public TimeSpan TimeOfDay
{
    get
    {
        return new TimeSpan(this.InternalTicks % 864000000000L);
    }
}

By accessing the TimeOfDay property on 2 DateTime instances over 2 million iterations you are creating 4 million Timespan instances. However, that’s not the biggest expense.

Digging further, you have:

internal long InternalTicks
{
    get
    {
        return (long)(this.dateData & 4611686018427387903uL);
    }
}

So you have 4 million instantiations, remainder calculations, casts, and & operations. These are all cheap operations (“cheap” of course being a relative term) but done in quantity they add up.

The actual comparison is trivial:

public static bool operator >(TimeSpan t1, TimeSpan t2)
{
    return t1._ticks > t2._ticks;
}

Compiling the OPs code in Debug mode, I see:

1. Empty loop: 4ms.
2. var a = firstDate > secondDate; 6ms (suggesting it is not optimized away)
3. var a = firstDate.TimeOfDay; 40ms
4. var a = firstDate.TimeOfDay > secondDate.TimeOfDay; 80ms
5. TimeSpan a = new TimeSpan( ticks ), b = new TimeSpan( ticks ); 7ms

Running a performance analysis in VS 2012 against the program, 81% of samples are coming from DateTime.get_TimeOfDay().

Running x64, Release mode, all optimizations enabled:

1. Empty loop: 3ms.
2. var a = firstDate > secondDate; 6ms
3. var a = firstDate.TimeOfDay; 20ms
4. var a = firstDate.TimeOfDay > secondDate.TimeOfDay; 40ms
5. TimeSpan a = new TimeSpan( ticks ), b = new TimeSpan( ticks ); 6ms

So:

• Micro-benchmarks can be misleading (though not useless).
• Enable optimizations before deciding there is a problem.
• Performance appears to double with optimization.
• The statements in question do not appear to be optimized away under any circumstance.
• Instantiation is a tangible but minor part of the expense.
• Cast/arithmetic operations account for the rest of the expense.
• Storing the property value in a variable before looping greatly improves performance.