php / php/php-src

Performance penalty for builtin/extension functions due to interrupt checks

オープン
#19,829 コメント 8 件 リアクション 1 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

Feature Status: Needs Triage
主要言語
C
スター
40.4k
フォーク
8.1k
平均マージ
2日 13時間
マージ済み PR(30日)
96

説明

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?

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

この issue ではファイルではなく、DO_FCALL と ZEND_VM_FCALL_INTERRUPT_CHECK が挙げられています。まず、VM が内部呼び出しに対する割り込みチェックをどこで実行しているのか、また高速な拡張関数がどのように表現されているのかを追跡してください。完了とするには、レビュー済みのエンジンレベルのアプローチに加え、割り込みの挙動を弱めることなくオーバーヘッドが削減されていることを示すベンチマークの証拠が必要です。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
c, php
領域
compilers, performance
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
停滞
明瞭さ
説明が足りない
初心者へのやさしさ
28/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。