regarding switch-case and if-else statements

[sam_cit]

Hi Everyone,

I read somewhere that there are some compile time operations behind
switch-case, which is why it can work for cases which evaluates to an
integer or character and not strings and that it makes switch-case
faster than if-else statements, is it true and if so what is the
underlying concept behind a switch-case compilation? Can anyone help in
this regard.

Thanks in advance!!!

 

[Chris Dollin]

(e-mail address removed) wrote:

(almost topical)

I read somewhere that there are some compile time operations behind
switch-case,

Yes. Code-generation happens at compile-time.

which is why it can work for cases which evaluates to an
integer or character and not strings

No. That's just an efficiency-oriented language-design issue.

and that it makes switch-case faster than if-else statements,

What (can) make switch-case faster than if-then chains is that all
the comparisions (can be) made in one go rather than an if at a
time.

is it true and if so what is the underlying concept behind a
switch-case compilation?

A switch-case where the case labels are dense in the range they
cover (so something like 1000..1020 rather than 1, 17, 32,
29, 123, 256, 501, ...) can often be implemented efficiently
by using an indexed jump instruction.

So the compiler (at compile-time) looks to see if that would be
a good way to implement the switch and, if it is, implements
it that way.

Any decent compiler book will discuss this.

 

[santosh]

Hi Everyone,

I read somewhere that there are some compile time operations behind
switch-case, which is why it can work for cases which evaluates to an
integer or character and not strings and that it makes switch-case
faster than if-else statements, is it true and if so what is the
underlying concept behind a switch-case compilation? Can anyone help in
this regard.

Thanks in advance!!!

Though the C standard does not consider the relative efficiency of
various constructs, generally for a large number, (say over 10), of
decisions which depend on the value of an integer, which is likely to
be within a reasonable range, the switch statement is likely to
generate faster code than a long series of if-else statements.

This is because, an index table may be used, which means that all the
branches are taken with at most one test. A series of if-else may mean
that to arrive at tests lower down in the chain, all the tests above
have to be gone through, so the very last if/else in the chain will
take the longest to be tested.

Note though that these are implementation dependant details. A compiler
might not generate a jump table for a switch statement and might do so
for an if-else statement. This depends on how good your compiler's
optimisations are.

 

[David T. Ashley]

Note though that these are implementation dependant details. A compiler
might not generate a jump table for a switch statement and might do so
for an if-else statement. This depends on how good your compiler's
optimisations are.

Two additional notes to the OP:

a)Some compilers I've worked with actually implement a switch as an else-if
below a certain threshold number of cases, usually 3-10. Setting up for a
jump table (in terms of generated code) is not without cost, so a switch()
construct has to be at least a certain size before it might make sense.

b)Note that switch() is different than else-if in that to get to one of the
lower cases in else-if, every test above has to be evaluated. This is not
true with switch().

 

[CBFalconer]

Two additional notes to the OP:

a)Some compilers I've worked with actually implement a switch as
an else-if below a certain threshold number of cases, usually 3-10.
Setting up for a jump table (in terms of generated code) is not
without cost, so a switch() construct has to be at least a certain
size before it might make sense.

While this may happen, the usual criterion is the size of the
prospective jump-table. The if-else may be more efficient than a
sparse table.

switch (i) {
case 1: ...
case 100: ...
case 1000: ...
default: ...
}

could cause an unnecessary monstrous case (jump) table, almost
entirely filled with pointers to the default code.

--
"The power of the Executive to cast a man into prison without
formulating any charge known to the law, and particularly to
deny him the judgement of his peers, is in the highest degree
odious and is the foundation of all totalitarian government
whether Nazi or Communist." -- W. Churchill, Nov 21, 1943

 

[David T. Ashley]

While this may happen, the usual criterion is the size of the
prospective jump-table. The if-else may be more efficient than a
sparse table.

switch (i) {
case 1: ...
case 100: ...
case 1000: ...
default: ...
}

could cause an unnecessary monstrous case (jump) table, almost
entirely filled with pointers to the default code.

You may be right, even with the compiler I mentioned. I had all contiguous
case tables, so the compiler's behavior with a sparse table was not
explored.

Phrased differently, for my application, the number of case labels and the
size of the jump table were always the same thing. The more general
behavior was not explored ...