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

先閱讀 PyErr_CheckSignals()、_PyErr_CheckSignalsTstate() 和 _PyRunRemoteDebugger()，著重於所述的低成本 flag 檢查與訊號處理順序。將提議的行為與基準測試和連結的 PR gh-157748 進行比較；當無訊號路徑的成本更低，且在設定 flag 時不改變行為時，該 issue 即完成。