Performance penalty for builtin/extension functions due to interrupt checks

Description

I was profiling an extension that's intended to act as a faster replacement for the pack() and unpack() functions. The functions in the extension are very fast - just a few instructions each.

During profiling I discovered, much to my surprise, that the overhead of the DO_FCALL opcode far exceeded the time actually spent in my function, and that 2/3rds of the overhead was coming from ZEND_VM_FCALL_INTERRUPT_CHECK.

Doing some digging I found that this interrupt check runs after every single internal function call. This means that my extension's functions are being overshadowed by interrupt checks on every call which are >5x slower than the actual function itself.

The net result overall is less visible (a 5-10% performance degradation in my synthetic test script), but I have to ask if there's a better way to do this. Why is PHP checking for interrupts after every internal function call? I get it for stuff like network and I/O functions which could take a long time, but not every builtin function is like that. For the fast ones, this is an unavoidable and (probably) unnecessary performance penalty.

I don't know much about how the interrupt system works, but my feeling is that there has to be a better way to implement it than having every internal function call pay such a penalty. Even if there was a way to avoid this interrupt check with some ZEND_ACC flag that would tell the engine a function is "fast" and not to do the interrupt check?

該 issue 提到的是 DO_FCALL 和 ZEND_VM_FCALL_INTERRUPT_CHECK，而不是某個檔案。首先追蹤 VM 在哪裡對內部呼叫執行中斷檢查，以及快速擴充函式是如何表示的。完成標準應包括一個經過審查的引擎層級方案，以及表明在不削弱中斷行為的情況下開銷有所降低的基準測試證據。