If-then-else v. switch-case
in [General Programming]
|
Prev: Ariadne Designs Ltd
Next: ANN: Seed7 Release 2010-07-18
From: Walter Banks on 18 Jul 2010 18:28 Frederick Williams wrote: > > In C is one of these faster than the other: > > if (P) > A; > else if (Q) > B; > else if (R) > C; > ... > else > D; > > switch (X) > { > case P: > A; > break; > case Q: > B; > break; > case R: > C; > break; > ... > default: > D; > } > > I realize it will depend on the compiler, and possibly the hardware, but > "in general"? This can be very much compiler dependent. In your switch example the distribution of the case labels often determines the compiler implementation choice which is some cases chooses something similar to if then else sequence. Regards, -- Walter Banks Byte Craft Limited http://www.bytecraft.com --- news://freenews.netfront.net/ - complaints: news(a)netfront.net ---
From: robin on 19 Jul 2010 11:36 Frederick Williams wrote in message <4C4300A0.B88A2483(a)tesco.net>... >In C is one of these faster than the other: > > if (P) > A; > else if (Q) > B; > else if (R) > C; > ... > else > D; > > > switch (X) > { > case P: > A; > break; > case Q: > B; > break; > case R: > C; > break; > ... > default: > D; > } > >I realize it will depend on the compiler, and possibly the hardware, but >"in general"? There's no requirement for anyu one to be faster than another. In any case, it's best to use what's clearest. If there are, say, 40 tests, then the CASE method is probably the clearer to write and to debug and maintain. That said, for specific cases there the tests involve constant values, the CASE method may well be faster than the IF method -- because the compiler can put those constants in a table, and use one table lookup to determine which CASE is required. Of course, the IF construct could be optimised the same way. However, I am not aware of any compilers (in general) that do that, but I have encountered compilers that optimise CASE.
From: rossum on 19 Jul 2010 13:39 On Sun, 18 Jul 2010 15:19:31 +0100, Richard Heathfield <rjh(a)see.sig.invalid> wrote: >and it doesn't mean that you shouldn't deliberately >make code slow, Ah... that brings back memories. A new database, with as yet very little data in it ran like the wind. We were asked to slow it down with a "minimum response time" so that quick transactions were delayed until after the preset minimum. That way, when the database filled up and got slower the users would not notice the slowdown. rossum
From: Richard Heathfield on 19 Jul 2010 19:36
rossum wrote: > On Sun, 18 Jul 2010 15:19:31 +0100, Richard Heathfield > <rjh(a)see.sig.invalid> wrote: > >> and it doesn't mean that you shouldn't deliberately >> make code slow, > Ah... that brings back memories. A new database, with as yet very > little data in it ran like the wind. We were asked to slow it down > with a "minimum response time" so that quick transactions were delayed > until after the preset minimum. That way, when the database filled up > and got slower the users would not notice the slowdown. Ah, that's a shame. How much better it would have been to give them the best you can give, all the time. But that's management for you. I am reminded of when I was learning how to write files in C. At the time, I had become accustomed to the speed of my Atari ST's 720KB floppy drive. So, when I was developing my first C file-handling program for an AT with its massive 20MB (or possibly 40MB) fixed disk, the program saved my test data so quickly that I assumed something had gone wrong! It took me rather longer than it should have done for me to assure myself that all was in fact well. On subsequent runs, I was *still* surprised - sufficiently so that I actually built a delay into the save routine so that the run would be less surprising. -- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ "Usenet is a strange place" - dmr 29 July 1999 Sig line vacant - apply within |