Thank you.
Well, the IL produced for the two is different. If you have the
following code:
bool b;
if (b)
i = 1;
else
i = 0;
i = (b ? 1 : 0);
The switch statement generates one extra line of IL compared to the if
statement. Whether or not this causes a performance impact, I wouldn't be
able to say (without seeing the native code produced). It could be that the
JIT compiler will optimize out the extra IL step, seeing it as unecessary.
Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- m...@spam.guard.caspershouse.com
"Dennis Myrén" <den...@oslokb.no> wrote in message
news:NZg6c.1495$zf6....@news4.e.nsc.no...
After seeing your question, I became curious myself, so I did some tests.
I tested two scenarios, dense switches, and sparse switches. With dense
switches, we are selecting from some set of values without skipping any
values in the middle. With sparse switches, we are selecting from values
that may skip around a lot.
In all cases, the machine code generated for switch() will out-perform that
generated for if().
The machine code generated for if() ... else if() ... is a pretty faithful
translation of the source code. There are machine jump instructions for
every value tested against, and they even appear in the same order as your
source code. There are O(n) jump instructions, and it isn't affected by
whether we're doing dense or sparse tests.
The machine code generated for switch() depends on whether we do a dense or
sparse test.
The dense switch() is extremely efficient, doing pointer arithmetic to
compute the destination address of it's *single* jump instruction. This
optimization is probably only possible thanks to the special IL instruction
"switch", which the C# compiler outputs in this situation. Here, we have
O(1) jump instructions.
The sparse switch() is also very efficient, it does a series of comparisons
paired with conditional jump instructions, and only jumps one time, to the
desired case. Here, we also have O(1) jump instructions (that are actually
executed).
In addition to this, the sparse switch does all comparisons and conditional
jumps in one big stretch of machine code, which is really good for CPU
caches. The machine code for if() jumps all over the place to arrive at its
destination, so if you do a lot of work in each if(), there will be a bunch
of stuff to jump over - and therefore the locality of reference goes way
down. That translates to CPU cache misses, which are performance killers.
Another thing to consider with the dense switch() is that IL is expressive
enough to capture the compiler's intent in this situation, so the JIT for
other potential platforms may be able to optimize it even better (though
they'll have a hard time beating O(1)).
Conclusion: switch always out-performs if. That said, when there are a
small number of tests, you may choose if() just for readability if it makes
sense in a particular situation.
I only tested switch on integer types.. not strings. I suspect that
switch() would still outperform if() in this case due to locality of
reference.
Mike
Mike, I saw a post a couple months ago that indicated that switches on
strings use hash tables when there are around 12 or more cases (I
forget the exact number). So that should be much faster than the
equivalent 'if' tests.
"Michael Sparks" <michael...@remove.this.sbcglobal.net> wrote in message
news:P%j6c.94$1P6...@newssvr23.news.prodigy.com...
"_e_" <_nom...@nomail.com> wrote in message
news:ppal50t6m0u4vprbb...@4ax.com...
with regards,
J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!