The issue is that there are many different "simple cases". The more checks for "fast paths" you add, the more overhead of individually checking for them. Also

The issue is that there are many different "simple cases". The more checks for "fast paths" you add, the more overhead of individually checking for them. Also consider that: - this is more branch predictor friendly (a generic opcode encounters many different cases, while a specialized opcode is expected to almost never fail), - the inline cache has limited space and is stateful (imagine it's a C union of cache structs for different fast paths). If your "generic" LOAD_ATTR found a simple case B, it'd still need to ensure that its inline cache was actually primed for simple case B. This is not the issue with specialized opcodes; the cache is set to correct state when the opcode gets specialized.