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

Bắt đầu bằng cách đọc PyErr_CheckSignals(), _PyErr_CheckSignalsTstate() và _PyRunRemoteDebugger(), tập trung vào thứ tự được nêu của các phép kiểm tra flag có chi phí thấp và việc xử lý tín hiệu. So sánh hành vi được đề xuất và các benchmark với PR được liên kết gh-157748; issue được hoàn thành khi đường đi không có tín hiệu có chi phí thấp hơn mà không thay đổi hành vi khi các flag được thiết lập.