Speaking from the point of view of how the compiler *implements* a switch is probably the best way to go.
Very often you have something like:
switch(val) {
case 0: stuff(); break;
case 1: stuff1(); break;
case 2: ...
...
case 29: oddball stuff(); break;
case 87: moreoddballstuff(); break;
default: dodefault(); break;
}
There are often a large number of cases which are regular, that is, separated in value by a fixed amount (not necessarily listed together) along with some oddball cases and perhaps a default.
When possible, those cases that are regularly spaced are implemented by computed branching. If you are switching on a value that is in such a range, the switch() will run very quickly and take little memory to implement as computed branching is very efficient.
What remains is a series of if/else if/else if/else computations or possibly a series of if/if/if statements. Depending on how the compiler ordered these (by value or by order of appearance), your switch could take quite a bit of time to execute (to find the correct "if" statement).
If there are not a series of regularly spaced case values, then it all comes down to a series of tests of either if/else if/.. or if/if/...
It doesn't matter which because in the special situation of a switch statement, the compiler or possibly the optimizer, will modify the generated code so that they wind up the same.
All this gets thrown out if you have fall-through cases, of course.
Some compilers will start out with a min-max range test to see if the value is mentioned in ANY of the cases and either go to the default or do nothing. This could happen even if there are "holes" in the cases as it is typically a very small and fast check to make.
So, there isn't a good one-to-one relationship with the general switch() statement with a particular pattern of if/else if/else or if/if/if statements. It depends on the case values and the compiler implementation and what impact the optimizer has. A lot of work is done by the compiler to make a switch() faster than a pure if/else if/else if/else sequence but if the cases are irregular and widely spaced, it is limited in the optimization.