There is no guarantee that the value in the switch(value) instruction is one of the string constants.
If it is possible that it has the same hash, but is a different value, then an actual comparison has to follow the selection of the branch with the matching hash.
Yes, a final == comparison is needed between
string content, of course.
If you really want to optimize, then there are faster ways than hashing:
switch (color) {
case "red":
case "blue":
case "green":
}
only the first letter (r or b or g) or e.g. only the second letter (e or l or r) can be read to know, which one it is, iff you know, color is one of the three string values.
What you're describing is a Trie. Double-array
compile-time Trie and compile-time string
binary search leads to a slightly different kind
of strategies where each action to emit
after a search hit is a goto address as
opposes to a final computed goto, but the codegen
for the switch body remains the same.
Perfect hash + computed jump is just one of
implementation strategies and may fit longer string
constants.
> So... you want it to break if there's a hash collision? I'm not sure
> if I can call that an "optimization".
The entries are known before forming the
table, so collision can be avoided by
perfect hashing.
See also https://github.com/serge-sans-paille/frozen