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:
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; }
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; }
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:
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:
shift
equals true while if/else branches when shift
is false. shift
is either true or false, are equal for the two.Do any of these observations imply that the conditional operator will perform slower? Is there other side-effects that come into play?
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.
I would be curious to know if you are testing this with a Debug or Release build. If it is a debug build, then the difference could quite likely be a difference due to the LACK of low-level optimizations that the compiler adds when you use Release mode (or manually disable debug mode and enable compiler optimizations.)
I would expect with optimizations on, however, that the ternary operator is either the same speed or a bit faster than the if/else statement, while the dictionary lookup is slowest. Here are my results, 10 million warm-up iterations followed by 10 million timed, for each:
DEBUG MODE
If/Else: 00:00:00.7211259 Ternary: 00:00:00.7923924 Dictionary: 00:00:02.3319567
RELEASE MODE
If/Else: 00:00:00.5217478 Ternary: 00:00:00.5050474 Dictionary: 00:00:02.7389423
I think it is interesting to note here that before optimizations were enabled, ternary computation was slower than if/else, while after, it was faster.
EDIT:
After a bit more testing, in a practical sense, there is little to no difference between if/else and ternary. While the ternary code results in smaller IL, they perform pretty much the same as each other. In a dozen different tests with a release mode binary, the if/else and ternary results were either identical, or off by a fraction of a millisecond for 10,000,000 iterations. Sometimes if/else was slightly faster, sometimes ternary was, but in all practicality, they perform the same.
Dictionary performs significantly worse, on the other hand. When it comes to these kinds of optimizations, I would not waste my time choosing between if/else and ternary if the code already exists. However, if you currently have a dictionary implementation, I would definitely refactor it to use a more efficient approach, and improve your performance by some 400% (for the given function, anyway.)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With