Can you explain why this is?
Intuitively it would seem like optimizing a switch statement would be really low-hanging fruit. I would have thought it would be optimized into something almost exactly like what the author hand rolled.
Can you explain why this is?
Intuitively it would seem like optimizing a switch statement would be really low-hanging fruit. I would have thought it would be optimized into something almost exactly like what the author hand rolled.
switch(3) {
case true: break;
case "ab" + "c": break;
case Math.random() >= 0.5 ? "heads" : new Error("tails") : break;
}
The optimizer will have to be persuaded that the switch and each case is integral before optimizing with a jump table. On the other hand, Arrays typically have a fast path for integer indices.> @LGB actually in V8 (JS engine used by google chrome) you need to jump through a lot of hoops to get switch case optimized: All the cases must be of same type. All the cases must either be string literals or 31-bit signed integer literals. And there must be less than 128 cases. And even after all those hoops, all you get is what you would have gotten with if-elses anyway (I.E. no jump tables or sth like that). True story.
In the case of this emulator, it wasn’t being optimized because it had more than 128 cases.
Now that makes sense. Thank you.
E.g. Random.random() will have to be called each time that case branch is evaluated, because that function could be overloaded or change its returned value.