Asserting Performance Bottlenecks

Asserts can also warn you when code performance falls below a certain threshold. Suppose you have some speed-critical code in an inner loop. If the timing of that section ever exceeds X milliseconds, then you might add an assert to notify you that your code is running slower than expected. That'll give you a head start on deciding where to optimize. The point here isn't to replace a traditional performance profiler. The point is just to make sure that the developer will be instantly informed if this unexpectedly bad performance ever happens.

using System.Diagnostics;
class TimingTest {
    public static void Main() {
        #if DEBUG
            const int maxExpectedTime = 500; //.5 seconds
            System.DateTime startTime = System.DateTime.Now;
            #endif
        //First speed-critical section of code here
            ...
        #if DEBUG
            System.DateTime endTime = System.DateTime.Now;
            System.TimeSpan elapsedTime = endTime.Subtract(startTime);
            Debug.Assert(elapsedTime.Milliseconds <= maxExpectedTime,
                "First section took too long");
            startTime = System.DateTime.Now;
            #endif
        //Second speed-critical section of code here
            ...
        #if DEBUG
            endTime = System.DateTime.Now;
            Debug.Assert(elapsedTime.Milliseconds <= maxExpectedTime,
                "second section took too long");
        #endif
    }
}

In the preceding code snippet, there are two pieces of speed-critical code. A real-world example might have four or five speed-critical "hot spots." When you run this program, you notice the feature is slow and you suspect the bottleneck is occurring in one of the known speed-critical sections—but without running a performance profiler, you couldn't tell which one. Yet these asserts will tell you if any section takes longer than expected, so that helps pinpoint which section is taking too long. And what if none of the asserts fire? Then that would prove the bottleneck is not in any known hot spots, so get out that profiler to identify the real culprit.

You probably don't have a firm estimate for the number of milliseconds a piece of code should require—developers tend to be very bad at predicting such things. But you can make some good, conservative estimates. Just ask how long a typical user would be willing to wait for a feature to run. Two seconds? Thirty seconds? Put an assert around the feature stating it should never take longer than your chosen value. Don't forget, though, that various factors make it difficult to reliably time intervals less than about.2 seconds. Better to assert on longer intervals.

Debug.Assert(version == Exch55, "This won't handle Exchange 2K yet");