I'm unsure. They're different enough in structure that it feels to me that it should be a conscious decision. In a switch statememt, there's usually one large scope, while in the function table there's a lot of little scopes. The pathway through the code during execution is different ad well. Massive switch statements are also not reasonable situations from the perspective of a compiler, as they see little use outside of VMs.
Sure, I mean more in terms of producing a compiled form with O(1) rather than O(n) performance.
> Massive switch statements are also not reasonable situations from the perspective of a compiler, as they see little use outside of VMs.
I'm not really following this logic, massive switch statements are those that can benefit most significantly from the generation of jump tables.
And what needs to be done to generate them doesn't differ significantly based upon the branch count (when you hit case 0x100 you'll need to switch to 16-bit, so binary size will be impacted).
The fact that it's primary use case is reasonably niche is fairly irrelevant given there's bugger all compiler overhead required for support.
Now from a code perspective, I would say that a statement that large probably isn't ideal (depending on the size of your case blocks).
> Now from a code perspective, I would say that a statement that large probably isn't ideal (depending on the size of your case blocks).
This is what I had meant, yes. Optimizing such large blocks is quite difficult. A case label in C and C-like languages does not even need a block, making it harder.
> The fact that it's primary use case is reasonably niche is fairly irrelevant given there's bugger all compiler overhead required for support.
Even static C compilers still struggle with optimizing the switch-in-for-loop pattern, let alone a JIT compiler. Clang does the best job nowadays, but it still lags behind other methods like computed goto or continuation-passing. The Python VM will switch to computed goto if it's available on the C compiler.
It does take work to make a faster VM, it feels unreasonable to expect a compiler to do a good job at optimizing it without effort on the writer's side.
In the grand scheme of things, VMs and interpreters are a class of program that tend toward perhaps surprisingly pathological behaviour, among programs people are likely to write.
