|optimizing case-statement execution email@example.com (1992-11-22)|
|Re: optimizing case-statement execution chased@rbbb.Eng.Sun.COM (1992-11-23)|
|Re: optimizing case-statement execution firstname.lastname@example.org (1992-11-25)|
|Re: optimizing case-statement execution nr@volkl.Princeton.EDU (1992-11-25)|
|Re: optimizing case-statement execution email@example.com (1992-11-27)|
|Re: optimizing case-statement execution firstname.lastname@example.org (1992-12-04)|
|Re: optimizing case-statement execution krste@ICSI.Berkeley.EDU (1992-12-05)|
|From:||chased@rbbb.Eng.Sun.COM (David Chase)|
|Organization:||Sun Microsystems, Mt. View, Ca.|
|Date:||Mon, 23 Nov 1992 20:44:07 GMT|
|Keywords:||C, code, optimize|
email@example.com (Ray Kamin) writes:
>How do compilers (in my case gcc v2.2.2) handle large switch statements?
>I have a 120 way switch in my code. I looked at the sparc assembly code
>produced by gcc and it apparently doesn't use any sort of jump table, but
>merely does sequential comparisons and branches.
>With this in mind, I rewrote the code [with an array of function pointers].
>The code is working correctly, however, it is not any faster at all. Does
>anyone have any insight into this, or how this should be written for speed?
Sure -- log N grows pretty slowly. I'm pretty sure that 120 compact
cases go faster if you use a table lookup, but not by much. Last time
I looked hard at this, break-even was somewhere around 32 (for
"binary" (*) search versus table lookup), but handling 128 cases is
only two compares and two branches more per switch execution. You're
lucky your code didn't run slower, seeing as how you added parameter
movement, a return, and (possibly) a SAVE and RESTORE pair per switch
>[There are three general ways to generate code for a switch: a jump table,
>...a binary-compare and branch tree, ... a sequential compare and branch.
Don't forget hash tables, though they may not always be appropriate.
(*) "Binary" means that the appropriately weighted tree should be in
cost-balance. This includes accounting both for case-frequency and
taken/not-taken branch costs.
Return to the
Search the comp.compilers archives again.