Python 3.15's Ultra-Low Overhead Interpreter Profiling Mode – Ken Jin's Blog

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 ?

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.