27

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?

Peter Lillevold
  • 33,668
  • 7
  • 97
  • 131
  • 7
    You mean the "conditional" operator, yes? – Marc Gravell Feb 14 '10 at 00:53
  • 7
    Officially, it is the "conditional operator", but I often hear it referred to as "the" ternary operator. As far as I know, its the only operator in C# that takes three arguments. So who's to quibble about nomenclature? :) – Nathan Feb 14 '10 at 00:58
  • 1
    I don't know about "always should do". My first reflex would be first to look at the target code to make sure 1/ and 2/ are indeed compiled differently. Next, do you need to care? Even if they aren't compiled in the same efficient code now, they might be in the next version of your compiler. The knowledge you are trying to acquire has at best temporary value. – Pascal Cuoq Feb 14 '10 at 00:59
  • 4
    A ternary operator is simply an operator that takes three arguments ;-) http://en.wikipedia.org/wiki/Ternary_operation – Eric J. Feb 14 '10 at 00:59
  • Are you resetting your stop watch ?? I had some similar issue before. see http://stackoverflow.com/questions/2223248/performance-consideration-when-using-properties-multiple-times – ram Feb 14 '10 at 01:12
  • 6
    It sounds like all three of these options take a fraction of a nanosecond. I'm pretty sure sweating this is a huge waste of your valuable time. – ojrac Feb 14 '10 at 01:45
  • I agree with @ojrac, this sounds like a ridiculously early pre-optimization. – Justin Johnson Feb 14 '10 at 18:53
  • @ojrac and @Justin - how can you without me giving further context assume that this is early pre-optimization and a waste of my time? Anyways, I've received a load of good hints and suggestions here to move on to figure out whats causing the difference in constructs 1) and 2). – Peter Lillevold Feb 14 '10 at 20:31
  • I assume it's a waste of time because you are dealing in nanoseconds, which is an incredibly low level of optimization. If you really do need to process key checks at a rate of over 50 million per second, then keep on optimizing. – ojrac Feb 16 '10 at 14:56
  • 1
    It is still not the optimization that is central here. It is the question why the conditional operator can be four times slower than a regular if/else statement, and even two times slower than a dictionary lookup. – Peter Lillevold Feb 16 '10 at 21:26
  • Did you use random input for each cycle, or constant? If random, it is possible, however unlikely, that one of the first two options got a bad shake. The dictionary lookup, however slow, should be near constant, while others at least have the potential to be quite long. – Dustman Feb 17 '10 at 00:10
  • Totally agreed with @ojrac. I'd bet large sums of money that this is nowhere near an actual bottleneck in the code. If this code is causing you a performance issue, it seems highly likely that there's a way to fix it by simply *not calling this code as frequently*. The best way to optimize is usually to find a way to not do the work at all! – kyoryu Feb 22 '10 at 00:40
  • 1
    And, at any rate, if I were to try to optimize this, the first thing I'd do is have a single if statement at the beginning that checks to see if shift is true, and then goes to two entirely separate switch statements. – kyoryu Feb 22 '10 at 00:42
  • @Peter, I have often found myself in a DEBUG/TRANCE. Glad I am not the only one. lol. – Sky Sanders Feb 22 '10 at 01:58
  • 1
    @Kyoryu - yes, that is what I'm actually doing in my production code right now. Still, my question is not about how to best optimize the method, but *why* the two statements perform different. – Peter Lillevold Feb 22 '10 at 03:02

8 Answers8

13

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.

Yvo
  • 18,681
  • 11
  • 71
  • 90
  • 2
    I did some testing, and the moment you throw in .ToString(), performance tanks. String operations are some of the slowest, and manually testing for explicit values and converting as in the original examples, while more verbose, is significantly faster. – jrista Feb 14 '10 at 02:34
  • Yeah ToString() isn't the fastest solution, but it would save a lot of code. If performance is an issue go for the ifs/operator. – Yvo Feb 14 '10 at 13:42
  • Inspecting the IL is something I'm working on now. And yes, I was also expecting to see equal perf with if/else and the conditional operator. But really, if saving lines of code was my ultimate goal then I would go for my dictionary sample, it is clean and fast and works for both regular and special cases without extra logic. – Peter Lillevold Feb 14 '10 at 20:35
  • @Peter: I am not sure exactly how you are getting your performance numbers, but the dictionary sample performed some 400% SLOWER than the other two alternatives in my testing. A difference of half a second for if/ternary vs. nearly 3 seconds for dictionary. I wouldn't bet on a dictionary implementation actually being very fast at all, even if it looks more compact. – jrista Feb 15 '10 at 04:51
  • @Zyphrax - see my updated question. Actually, is seems that it is if/else that tests the opposite condition. Can it be this difference that yields the performance boost for if/else instead of the conditional operator? – Peter Lillevold Feb 22 '10 at 00:18
  • @Peter: it could be making a small difference, at some point (many abstraction levels deeper than c#) it all comes down to how many times the memory is being accessed, how many processor cycles it takes to process your (optimized) statement etc. etc.. But we're talking about a difference of a few millisec. over a million cycles. Do those few millisec. really matter that much? – Yvo Feb 22 '10 at 10:54
11

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.)

jrista
  • 32,447
  • 15
  • 90
  • 130
  • I'm curious as to how you you construct your dictionary sample. Your numbers here does not at all compare to mine. What type are you using for lookup? – Peter Lillevold Feb 15 '10 at 07:23
  • I copied and pasted your code...its identical. My times are for all 10 million iterations, not a single request (resolution of the stopwatch starts getting inaccurate when you are talking about a few nanoseconds, so I find measuring the entire process to be a more effective test.) – jrista Feb 15 '10 at 19:04
  • Are you counting initializing your dictionary within the dictionary timing? I don't. And yes, I'm also running release mode with optimizations. – Peter Lillevold Feb 22 '10 at 00:22
  • @Peter: No, the dictionary is initialized before timing. I would be curious to see your implementation...if I could get my dictionary performance to approach yours, that would great. I've never seen .NET dictionaries perform that well. – jrista Feb 24 '10 at 19:12
  • @Peter: Yeah, thats the same code I have, as I copied that part. I meant the code that actually does the timing and measuring. I've measured the time it takes to complete all 10 million iterations as a chunk. Perhaps that is causing some kind of difference between your measurement and mine. – jrista Feb 24 '10 at 19:48
  • @Peter: Thanks! When I get home, I'll try some more testing, and see what numbers I get. – jrista Feb 24 '10 at 20:33
4

Interesting, I went off and developed a small class IfElseTernaryTest here, ok, the code is not really 'optimized' or good example but nonetheless...for the sake of the discussion:

public class IfElseTernaryTest
{
    private bool bigX;
    public void RunIfElse()
    {
        int x = 4; int y = 5;
        if (x &gt; y) bigX = false;
        else if (x &lt; y) bigX = true; 
    }
    public void RunTernary()
    {
        int x = 4; int y = 5;
        bigX = (x &gt; y) ? false : ((x &lt; y) ? true : false);
    }
}

This was the IL dump of the code...the interesting part was that the ternary instructions in IL was actually shorter than the if....

.class /*02000003*/ public auto ansi beforefieldinit ConTern.IfElseTernaryTest
       extends [mscorlib/*23000001*/]System.Object/*01000001*/
{
  .field /*04000001*/ private bool bigX
  .method /*06000003*/ public hidebysig instance void 
          RunIfElse() cil managed
  // SIG: 20 00 01
  {
    // Method begins at RVA 0x205c
    // Code size       44 (0x2c)
    .maxstack  2
    .locals /*11000001*/ init ([0] int32 x,
             [1] int32 y,
             [2] bool CS$4$0000)
    .line 19,19 : 9,10 ''
//000013:     }
//000014: 
//000015:     public class IfElseTernaryTest
//000016:     {
//000017:         private bool bigX;
//000018:         public void RunIfElse()
//000019:         {
    IL_0000:  /* 00   |                  */ nop
    .line 20,20 : 13,23 ''
//000020:             int x = 4; int y = 5;
    IL_0001:  /* 1A   |                  */ ldc.i4.4
    IL_0002:  /* 0A   |                  */ stloc.0
    .line 20,20 : 24,34 ''
    IL_0003:  /* 1B   |                  */ ldc.i4.5
    IL_0004:  /* 0B   |                  */ stloc.1
    .line 21,21 : 13,23 ''
//000021:             if (x &gt; y) bigX = false;
    IL_0005:  /* 06   |                  */ ldloc.0
    IL_0006:  /* 07   |                  */ ldloc.1
    IL_0007:  /* FE02 |                  */ cgt
    IL_0009:  /* 16   |                  */ ldc.i4.0
    IL_000a:  /* FE01 |                  */ ceq
    IL_000c:  /* 0C   |                  */ stloc.2
    IL_000d:  /* 08   |                  */ ldloc.2
    IL_000e:  /* 2D   | 09               */ brtrue.s   IL_0019

    .line 21,21 : 24,37 ''
    IL_0010:  /* 02   |                  */ ldarg.0
    IL_0011:  /* 16   |                  */ ldc.i4.0
    IL_0012:  /* 7D   | (04)000001       */ stfld      bool ConTern.IfElseTernaryTest/*02000003*/::bigX /* 04000001 */
    IL_0017:  /* 2B   | 12               */ br.s       IL_002b

    .line 22,22 : 18,28 ''
//000022:             else if (x &lt; y) bigX = true; 
    IL_0019:  /* 06   |                  */ ldloc.0
    IL_001a:  /* 07   |                  */ ldloc.1
    IL_001b:  /* FE04 |                  */ clt
    IL_001d:  /* 16   |                  */ ldc.i4.0
    IL_001e:  /* FE01 |                  */ ceq
    IL_0020:  /* 0C   |                  */ stloc.2
    IL_0021:  /* 08   |                  */ ldloc.2
    IL_0022:  /* 2D   | 07               */ brtrue.s   IL_002b

    .line 22,22 : 29,41 ''
    IL_0024:  /* 02   |                  */ ldarg.0
    IL_0025:  /* 17   |                  */ ldc.i4.1
    IL_0026:  /* 7D   | (04)000001       */ stfld      bool ConTern.IfElseTernaryTest/*02000003*/::bigX /* 04000001 */
    .line 23,23 : 9,10 ''
//000023:         }
    IL_002b:  /* 2A   |                  */ ret
  } // end of method IfElseTernaryTest::RunIfElse

  .method /*06000004*/ public hidebysig instance void 
          RunTernary() cil managed
  // SIG: 20 00 01
  {
    // Method begins at RVA 0x2094
    // Code size       27 (0x1b)
    .maxstack  3
    .locals /*11000002*/ init ([0] int32 x,
             [1] int32 y)
    .line 25,25 : 9,10 ''
//000024:         public void RunTernary()
//000025:         {
    IL_0000:  /* 00   |                  */ nop
    .line 26,26 : 13,23 ''
//000026:             int x = 4; int y = 5;
    IL_0001:  /* 1A   |                  */ ldc.i4.4
    IL_0002:  /* 0A   |                  */ stloc.0
    .line 26,26 : 24,34 ''
    IL_0003:  /* 1B   |                  */ ldc.i4.5
    IL_0004:  /* 0B   |                  */ stloc.1
    .line 27,27 : 13,63 ''
//000027:             bigX = (x &gt; y) ? false : ((x &lt; y) ? true : false);
    IL_0005:  /* 02   |                  */ ldarg.0
    IL_0006:  /* 06   |                  */ ldloc.0
    IL_0007:  /* 07   |                  */ ldloc.1
    IL_0008:  /* 30   | 0A               */ bgt.s      IL_0014

    IL_000a:  /* 06   |                  */ ldloc.0
    IL_000b:  /* 07   |                  */ ldloc.1
    IL_000c:  /* 32   | 03               */ blt.s      IL_0011

    IL_000e:  /* 16   |                  */ ldc.i4.0
    IL_000f:  /* 2B   | 01               */ br.s       IL_0012

    IL_0011:  /* 17   |                  */ ldc.i4.1
    IL_0012:  /* 2B   | 01               */ br.s       IL_0015

    IL_0014:  /* 16   |                  */ ldc.i4.0
    IL_0015:  /* 7D   | (04)000001       */ stfld      bool ConTern.IfElseTernaryTest/*02000003*/::bigX /* 04000001 */
    .line 28,28 : 9,10 ''
//000028:         }
    IL_001a:  /* 2A   |                  */ ret
  } // end of method IfElseTernaryTest::RunTernary

So it seems, that ternary operator is apparently shorter and I would guess, faster as less instructions is used...but on that basis, it seems to contradict your case #2 which is surprising...

Edit: After Sky's comment, suggesting 'code bloat for #2', this will disprove what Sky said!!! Ok, the Code is different, the context is different, it's an example exercise to check the IL dump to see...

t0mm13b
  • 34,087
  • 8
  • 78
  • 110
  • I was 'suspecting' and you could be right but your example does not prove this. It only proves that the code for the statement you compiled optimizes smaller. It is a simple thing to compile the code given and actually show proof.... – Sky Sanders Feb 14 '10 at 02:15
3

I would expect #1 and #2 to be the same. The optimizer should result in the same code. The dictionary in #3 would expected to be slow, unless it is optimized somehow to not actual use a hash.

When coding real-time systems, we always used a look-up table--a simple array--to translate as given in your example. It's the fastest when the range of input is fairly small.

Doug Domeny
  • 4,410
  • 2
  • 33
  • 49
  • I don't understand why you are downvoted. The OP has misunderstood how fast dictionary lookups should be, and you're making that clear. – Noon Silk Feb 14 '10 at 02:07
  • @silky, Thanks! I don't know why I was downvoted either. They didn't leave a comment. – Doug Domeny Feb 14 '10 at 13:01
  • Seriously. I know what to expect from the dictionary sample. I clearly state that I expect it to be slower. My whole question stems from the fact that my conditional operator sample was far slower than both if/else AND the dictionary. A lookup table is an ok suggestion and I might add a sample based on that to my test bed. – Peter Lillevold Feb 14 '10 at 20:42
2

I don't quite understand why you would expect an if statement to be slower than a dictionary lookup. At the very least a hashcode needs to be calculated and then it needs to be looked up in a list. I don't see why you would assume this is faster than a cmp/jmp.

Specifically, I don't even think the method you're optimising is that great; it seems that it could be made better at the calling stage (though I can't be sure, as you haven't provided the context).

Noon Silk
  • 54,084
  • 6
  • 88
  • 105
  • I didn't expect the if/else NOR the conditional to be slower than a dictionary, I stated that I expect the dictionary lookup to be slower. The reason for including a dictionary sample in the first place was merely to have some ground for comparison. – Peter Lillevold Feb 14 '10 at 20:44
1

Assuming you're concerned about the performance of that method (and if you're not, why bother posting it?), you should consider storing the char values in an array and converting the Key values to an index into the array.

Robert Rossney
  • 94,622
  • 24
  • 146
  • 218
  • 1
    I am concerned about the performance of the method and to that end, is able to optimize it to an acceptable measure. This is not the question though, the question is why the conditional operator perform worse than an equivalent if-else statement. – Peter Lillevold Feb 22 '10 at 03:05
  • If 50% of the text of your question is not germane to the question you want answered, it really wouldn't hurt to omit it. – Robert Rossney Feb 22 '10 at 09:15
0

I don't have VS to hand but surely there's a simple built-in way to get the key as a character? Something like a toString method so you can replace that monstrous switch with this:

if (shift)
  return inKey.toString().toUppercase();
else
  return inKey.toString().toLowercase();
DisgruntledGoat
  • 70,219
  • 68
  • 205
  • 290
  • ...which would make the code nice and simple, but would totally ruin performance. None of these are the focus of my question though, I'm looking for the reason why the conditional operator performs slower than the if/else statement. – Peter Lillevold Feb 22 '10 at 00:24
  • Really, it would ruin performance? Have you tested anything like the code I posted? Sure it may be slightly slower, but only a few ms in the grand scheme of things. – DisgruntledGoat Feb 22 '10 at 16:36
-1

I would choose the third option only because it is more readable/maintainable. I bet this code isn't the bottleneck of your application performance.

Jader Dias
  • 88,211
  • 155
  • 421
  • 625
  • 8
    This doesn't address the question. The question wasn't which version should be chosen, the question is attempting to get at the underlying reason for an unexpected result. – Nathan Feb 14 '10 at 01:03