Reduce overhead of PyErr_CheckSignals

Feature or enhancement

Proposal:

PyErr_CheckSignals() is the API long-running C loops use to stay interruptible. In the common case (no signal arrived) the call currently does, in order:

1. _PyRunRemoteDebugger() (since gh-131591, 3.14): a call that fetches the interpreter config via _PyInterpreterState_GetConfig() before looking at the pending flag;
2. _Py_ThreadCanHandleSignals(): _Py_IsMainThread() calls PyThread_get_thread_ident() and therefore pthread_self(), plus _Py_IsMainInterpreter();
3. only then _PyErr_CheckSignalsTstate(), whose first line is the cheap is_tripped test that returns immediately.

That is about 100 instructions per call.

Proposal

Test the cheap flags first, without changing what is done when they are set:

• _PyErr_CheckSignalsTstate() does the main-thread check itself, after its existing is_tripped test, so PyErr_CheckSignals() and the eval loop just call it; the handler-running body moves to an out-of-line helper so the early return stays cheap;
• _PyRunRemoteDebugger() tests debugger_pending_call before fetching the config.

Results

Non-PGO build, pyperf:

Notes: the gain for the arithmetic cases are not too important, they can be handled directly as well. See https://github.com/python/cpython/issues/157742.

Has this already been discussed elsewhere?

Related: gh-131591, gh-133465

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

Linked PRs

• gh-157748

Empieza leyendo PyErr_CheckSignals(), _PyErr_CheckSignalsTstate() y _PyRunRemoteDebugger(), centrándote en el orden indicado de las comprobaciones baratas de flags y del manejo de señales. Compara el comportamiento propuesto y los benchmarks con el PR vinculado gh-157748; el issue estará terminado cuando la ruta sin señales sea más barata sin cambiar el comportamiento cuando los flags estén establecidos.