> 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 mea

> 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. Best primer on the subject I have found, even if old: https://www.complang.tuwien.ac.at/forth/threaded-code.html https://www.complang.tuwien.ac.at/forth/threaded-code.html My own benchmarks from last year (note that these toy VMs may not be applicable to larger ones): https://github.com/shadowofneptune/threaded-code-benchmark https://github.com/shadowofneptune/threaded-code-benchmark 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.