Python 3.15’s Ultra-Low Overhead Interpreter Profiling Mode

Here are explanation on how to use it from one of the people working on it: https://www.youtube.com/watch?v=f1x4X83CDSA and the chunky docs that go with it in the beta of 3.15: https://docs.python.org/3.15/library/profiling.sampling.html

Could you duplicate `RECORD_INST` before each `INSTRUCTION_N`, so that:

```

   INSTRUCTION_1:
     // subroutine 1
     ip++;
     goto *dispatch_var[*ip];

   INSTRUCTION_2:
     // subroutine 2
     ip++;
     goto *dispatch_var[*ip];

becomes: ```

   RECORD_INST_1:
     // record logic
   INSTRUCTION_1:
     // subroutine 1
     ip++;
     goto *dispatch_var[*ip];

   RECORD_INST_2:
     // record logic
   INSTRUCTION_2:
     // subroutine 2
     ip++;
     goto *dispatch_var[*ip];

This way you could directly swap `dispatch_var` with an array populated with the `RECORD_INST_*` labels, and remove one step at runtime.

Or maybe this is what you are trying to avoid to reduce the binary size ?

I'm not clear on why there is `ip++` in the RECORD_INST handler. We've already moved to the next instruction by running `ip++` at the end of the handler in the normal dispatch table. In the RECORD_INST handler we do the work to record the instruction but don't do the actual work of that instruction. We can't, because we only have the one handler that has to work for all instructions. Shouldn't we jump to DISPATCHER_TABLE_NORMAL without incrementing ip again?

A `bool profile` branch stays expensive even when it predicts perfectly, because it bloats every opcode handler, and on a computed goto interpreter that extra code messes with the branch predictor history each dispatch site builds up, which is the whole reason dispatch is fast. Swapping the entire table dodges that. The part I like is fanning every opcode into one recording instruction and then back out through the real table, which is what keeps the second table from turning into a whole second interpreter like the earlier approach did.