Question

I was looking at some code with a huge switch statement and an if-else statement on each case and instantly felt the urge to optimize. As a good developer always should do I set out to get some hard timing facts and started with three variants:

1. The original code looks like this:

   public static bool SwitchIfElse(Key inKey, out char key, bool shift)
   {
       switch (inKey)
       {
          case Key.A: if (shift) { key = 'A'; } else { key = 'a'; } return true;
          case Key.B: if (shift) { key = 'B'; } else { key = 'b'; } return true;
          case Key.C: if (shift) { key = 'C'; } else { key = 'c'; } return true;
          ...
          case Key.Y: if (shift) { key = 'Y'; } else { key = 'y'; } return true;
          case Key.Z: if (shift) { key = 'Z'; } else { key = 'z'; } return true;
          ...
          //some more cases with special keys...
       }
       key = (char)0;
       return false;
   }
   

2. The second variant converted to use the conditional operator:

   public static bool SwitchConditionalOperator(Key inKey, out char key, bool shift)
   {
       switch (inKey)
       {
          case Key.A: key = shift ? 'A' : 'a'; return true;
          case Key.B: key = shift ? 'B' : 'b'; return true;
          case Key.C: key = shift ? 'C' : 'c'; return true;
          ...
          case Key.Y: key = shift ? 'Y' : 'y'; return true;
          case Key.Z: key = shift ? 'Z' : 'z'; return true;
          ...
          //some more cases with special keys...
       }
       key = (char)0;
       return false;
   }
   

3. A twist using a dictionary pre-filled with key/character pairs:

   public static bool DictionaryLookup(Key inKey, out char key, bool shift)
   {
       key = '\0';
       if (shift)
           return _upperKeys.TryGetValue(inKey, out key);
       else
           return _lowerKeys.TryGetValue(inKey, out key);
   }
   

Note: the two switch statements have the exact same cases and the dictionaries have an equal amount of characters.

I was expecting that 1) and 2) was somewhat similar in performance and that 3) would be slightly slower.

For each method running two times 10.000.000 iterations for warm-up and then timed, to my amazement I get the following results:

1. 0.0000166 milliseconds per call
2. 0.0000779 milliseconds per call
3. 0.0000413 milliseconds per call

How can this be? The conditional operator is four times slower than if-else statements and almost two times slower than dictionary look-ups. Am I missing something essential here or is the conditional operator inherently slow?

Update 1: A few words about my test harness. I run the following (pseudo)code for each of the above variants under a Release compiled .Net 3.5 project in Visual Studio 2010. Code optimization is turned on and DEBUG/TRACE constants are turned off. I run the method under measurement once for warm-up before doing a timed run. The run method executed the method for a large number of iterations, with shift set to both true and false and with a select set of input keys:

Run(method);
var stopwatch = Stopwatch.StartNew();
Run(method);
stopwatch.Stop();
var measure = stopwatch.ElapsedMilliseconds / iterations;

The Run method looks like this:

for (int i = 0; i < iterations / 4; i++)
{
    method(Key.Space, key, true);
    method(Key.A, key, true);
    method(Key.Space, key, false);
    method(Key.A, key, false);
}

Update 2: Digging further, I have looked at the IL generated for 1) and 2) and find that the main switch structures are identical as I would expect, yet the case bodies have slight differences. Here is the IL I’m looking at:

1) If/else statement:

L_0167: ldarg.2 
L_0168: brfalse.s L_0170

L_016a: ldarg.1 
L_016b: ldc.i4.s 0x42
L_016d: stind.i2 
L_016e: br.s L_0174

L_0170: ldarg.1 
L_0171: ldc.i4.s 0x62
L_0173: stind.i2 

L_0174: ldc.i4.1 
L_0175: ret 

2) The Conditional Operator:

L_0165: ldarg.1 
L_0166: ldarg.2 
L_0167: brtrue.s L_016d

L_0169: ldc.i4.s 0x62
L_016b: br.s L_016f

L_016d: ldc.i4.s 0x42
L_016f: stind.i2 

L_0170: ldc.i4.1 
L_0171: ret 

Some observations:

• The conditional operator branches when shift equals true while if/else branches when shift is false.
• While 1) actually compiles to a few more instructions than 2), the number of instructions executed when shift is either true or false, are equal for the two.
• The instruction ordering for 1) is such that only one stack slot is occupied at all times, while 2) always loads two.

Do any of these observations imply that the conditional operator will perform slower? Is there other side-effects that come into play?

Answer 1

Very odd, perhaps .NET optimization is backfireing in your case:

The author disassembled several
versions of ternary expressions and
found that they are identical to
if-statements, with one small
difference. The ternary statement
sometimes produces code that tests the
opposite condition that you would
expect, as in it tests that the
subexpression is false instead of
testing if it is true. This reorders
some of the instructions and can
occasionally boost performance.

http://dotnetperls.com/ternary

You want might consider the ToString on the enum value (for the non-special cases):

string keyValue = inKey.ToString();
return shift ? keyValue : keyValue.ToLower();

EDIT:
I’ve compared the if-else method with the ternary operator and with 1000000 cycles the ternary operator is always at least as fast as the if-else method (sometimes a few millisec faster, which supports the text above). I think that you’ve made somekind of error in measuring the time it took.