この投稿は、PHPスクリプトでBlackfireプロファイラーを使用してPHPを最適化することに関するものです。 以下のテキストは、 Blackfire Blog Articleの詳細な技術的説明です。

通常、strlenメソッドが使用されます。

if (strlen($name) > 49) { ... } 

ただし、このオプションはこれよりも約20％遅くなります。

 if (isset($name[49])) { ... } 

よさそうだ。 ソースを開いて、すべてのstrlen（）呼び出しをisset（）に置き換えようとしています。 しかし、 元の記事を注意深く読んだ場合、パフォーマンスが20％異なる理由は、 strlen（）の複数回の呼び出しで、 60〜80,000回の繰り返しであることがわかります。

なんで？

strlen（）がPHPの文字列の長さをどのように計算するかは問題ではありません。これらの文字列はすべて、このメソッドが呼び出される時点ですでにわかっているからです。 可能な限り、ほとんどはコンパイル時に計算されます。 メモリに送信されるPHP文字列の長さは、この文字列を含むC構造体にカプセル化されます。 したがって、 strlen（）は単にこの情報を読み取り、そのまま返します。 これはおそらく、何も計算しないため、PHP関数の中で最も高速です。 ソースコードは次のとおりです。

 ZEND_FUNCTION(strlen) { char *s1; int s1_len; if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s", &s1, &s1_len) == FAILURE) { return; } RETVAL_LONG(s1_len); } 

isset（）が関数ではないことを考えると、 strlen（）のパフォーマンスが20％低下する理由は、主にZendエンジンで関数を呼び出す際の関連する遅延によるものです。

別のポイントがあります： strlen（）のパフォーマンスを他のものと比較するとき、追加のオペコードが追加されます。 また、 isset（）の場合、使用される一意のオペコードは1つだけです。

逆アセンブルされたif（strlen（））構造の例：

 line #* IO op fetch ext return operands ----------------------------------------------------------------------------------- 3 0 > SEND_VAR !0 1 DO_FCALL 1 $0 'strlen' 2 IS_SMALLER ~1 42, $0 3 > JMPZ ~1, ->5 5 4 > > JMP ->5 6 5 > > RETURN 1 

そして、これはif（isset（））の意味的に等価な構造です：

 line #* IO op fetch ext return operands ----------------------------------------------------------------------------------- 3 0 > ISSET_ISEMPTY_DIM_OBJ 33554432 ~0 !0, 42 1 > JMPZ ~0, ->3 5 2 > > JMP ->3 6 3 > > RETURN 1 

ご覧のとおり、 isset（）コードには関数（DO_FCALL）の呼び出しは含まれていません。 また、オペコードIS_SMALLERはありません（RETURNステートメントは無視してください）。 isset（）はブール値を直接返します。 strlen（）は最初に一時変数を返し、次にそれがオペコードIS_SMALLERに渡され、最終結果はif（）を使用して計算されます。 つまり、2つのオペコードがstrlen（）構造で使用され、1つがisset（）構造で使用されます。 したがって、通常は1つの操作が2つよりも速いため、 isset（）の方がパフォーマンスが高くなります。

PHPでの関数呼び出しの仕組みとisset（）との違いを見てみましょう。

PHP関数呼び出し

最も難しい部分は、関数呼び出しに関連付けられている仮想マシンの部分（PHPコードが実行された瞬間）を分析することです。 関数呼び出しに関連する瞬間を掘り下げることなく、本質を述べようとします。

始めるために、呼び出しの実行時間を分析しましょう。 コンパイル時に 、PHP関数に関連する操作を実行するには多くのリソースが必要です。 ただし、オペコードキャッシュを使用すれば、コンパイル中に問題は発生しません。

特定のスクリプトをコンパイルしたとします。 実行時に何が起こるかだけを分析しましょう。 これは、内部関数（この場合はstrlen（） ）の呼び出しのオペコードのダンプがどのように見えるかです：

 strlen($a); line #* IO op fetch ext return operands ----------------------------------------------------------------------------------- 3 0 > SEND_VAR !0 1 DO_FCALL 1 'strlen' 

関数呼び出しのメカニズムを理解するには、次の2つのことを知る必要があります。

• 関数呼び出しとメソッド呼び出しは同じものです
• ユーザー関数呼び出しと内部関数呼び出しは異なる方法で処理されます

これが、最後の例が「内部」関数の呼び出しについて説明している理由です。strlen（）は、Cコードの一部であるPHP関数です。 「ユーザー定義」PHP関数（つまり、PHP言語で記述された関数）のオペコードをダンプした場合、まったく同じオペコードまたは他のオペコードを取得できます。

実際、この関数がPHPで認識されているかどうかに関係なく、コンパイル時に同じオペコードを生成しません。 明らかに、内部PHP関数はコンパイラーが開始する前に宣言されるため、コンパイル時に知られています。 ただし、カスタム関数は、宣言される前に呼び出される可能性があるため、明確でない場合があります。 実行について説明する場合、内部PHP関数はカスタム関数よりも効率的です。さらに、利用可能な検証メカニズムが多くあります。

上記の例から、関数呼び出しを制御するために複数のオペコードが使用されていることがわかります。 また、関数には独自のスタックがあることを覚えておく必要があります。 PHPでは、他の言語と同様に、関数を呼び出すには、最初にスタックフレームを作成し、関数に引数を渡す必要があります。 次に、これらの引数を必要に応じてスタックからプルする関数を呼び出します。 呼び出しの終わりに、以前に作成されたフレームを破棄する必要があります。

これは、関数呼び出しを扱うスキームが一般的な形でどのように見えるかです。 ただし、PHPは、スタックフレームを作成および削除する手順の最適化を提供します。 さらに、すべての関数呼び出しでこれらのジェスチャをすべて実行する必要がないように、実行を延期できます。

オペコードSEND_VARは、スタックフレームに引数を送信します。 コンパイラーは、関数を呼び出す前に必ずこのようなオペコードを生成します。 さらに、変数ごとに独自の変数が作成されます。

 $a = '/'; setcookie('foo', 'bar', 128, $a); line #* IO op fetch ext return operands ----------------------------------------------------------------------------------- 3 0 > ASSIGN !0, '%2F' 4 1 SEND_VAL 'foo' 2 SEND_VAL 'bar' 3 SEND_VAL 128 4 SEND_VAR !0 5 DO_FCALL 4 'setcookie' 

ここに別のオペコード-SEND_VALがあります。 合計で、関数スタックに何かを送信するための4種類のオペコードがあります。

• SEND_VAL ： 定数値 （文字列、整数など）を送信します
• SEND_VAR ：PHP変数（$ a）を送信します
• SEND_REF ：PHP変数を、リンクで引数を取る関数へのリンクとして送信します
• SEND_VAR_NO_REF ：ネストされた関数の場合に使用される最適化されたハンドラー

SEND_VARは何をしますか？

 ZEND_VM_HELPER(zend_send_by_var_helper, VAR|CV, ANY) { USE_OPLINE zval *varptr; zend_free_op free_op1; varptr = GET_OP1_ZVAL_PTR(BP_VAR_R); if (varptr == &EG(uninitialized_zval)) { ALLOC_ZVAL(varptr); INIT_ZVAL(*varptr); Z_SET_REFCOUNT_P(varptr, 0); } else if (PZVAL_IS_REF(varptr)) { zval *original_var = varptr; ALLOC_ZVAL(varptr); ZVAL_COPY_VALUE(varptr, original_var); Z_UNSET_ISREF_P(varptr); Z_SET_REFCOUNT_P(varptr, 0); zval_copy_ctor(varptr); } Z_ADDREF_P(varptr); zend_vm_stack_push(varptr TSRMLS_CC); FREE_OP1(); /* for string offsets */ CHECK_EXCEPTION(); ZEND_VM_NEXT_OPCODE(); } 

SEND_VARは、変数が参照かどうかを確認します。 その場合、それはそれを分離し、それによってリンクの不一致を作成します。 これが非常に悪い理由は、私の別の記事で読むことができます。 次に、SEND_VARが変数へのリンクの数（ここでのリンクはPHPの観点からのリンクではなく、つまり＆ではなく、この値を使用する数の単なるインジケーター）を変数に追加し、仮想マシンスタックに送信します。

 Z_ADDREF_P(varptr); zend_vm_stack_push(varptr TSRMLS_CC); 

関数を呼び出すたびに、スタックへの各変数引数の参照カウントを1ずつ増やします。 これは、変数が関数コードではなくスタックによって参照されるためです。 変数をスタックに送信してもパフォーマンスにはほとんど影響しませんが、スタックはメモリを消費します。 実行時にその中に配置されますが、サイズはコンパイル時に計算されます。 変数をスタックに送信した後、DO_FCALLを実行します。 以下は、PHP関数の呼び出しを「遅いステートメント」と見なすために使用されるコードとチェックの量の例です。

 ZEND_VM_HANDLER(60, ZEND_DO_FCALL, CONST, ANY) { USE_OPLINE zend_free_op free_op1; zval *fname = GET_OP1_ZVAL_PTR(BP_VAR_R); call_slot *call = EX(call_slots) + opline->op2.num; if (CACHED_PTR(opline->op1.literal->cache_slot)) { EX(function_state).function = CACHED_PTR(opline->op1.literal->cache_slot); } else if (UNEXPECTED(zend_hash_quick_find(EG(function_table), Z_STRVAL_P(fname), Z_STRLEN_P(fname)+1, Z_HASH_P(fname), (void **) &EX(function_state).function)==FAILURE)) { SAVE_OPLINE(); zend_error_noreturn(E_ERROR, "Call to undefined function %s()", fname->value.str.val); } else { CACHE_PTR(opline->op1.literal->cache_slot, EX(function_state).function); } call->fbc = EX(function_state).function; call->object = NULL; call->called_scope = NULL; call->is_ctor_call = 0; EX(call) = call; FREE_OP1(); ZEND_VM_DISPATCH_TO_HELPER(zend_do_fcall_common_helper); } 

ご覧のとおり、ここで小さなチェックが行われ、さまざまなキャッシュが使用されました。 たとえば、ハンドラーポインターが最初の呼び出しを検出し、その後の各呼び出しがこのポインターを使用できるように、仮想マシンのメインフレームにキャッシュされました。

次に、 zend_do_fcall_common_helper（）を呼び出します。 この関数のコードはここに投稿しませんが、ボリュームが大きすぎます。 そこで実行された操作のみを表示します。 要するに、これらは実行中に行われるさまざまなチェックです。 PHPは動的言語であり、実行時に新しい関数とクラスを宣言し、同時にファイルを自動的にアップロードできます。 そのため、PHPは実行時に多くのチェックを実行せざるを得ず、パフォーマンスに悪影響を及ぼします。 しかし、それを回避することはできません。

 if (UNEXPECTED((fbc->common.fn_flags & (ZEND_ACC_ABSTRACT|ZEND_ACC_DEPRECATED)) != 0)) { if (UNEXPECTED((fbc->common.fn_flags & ZEND_ACC_ABSTRACT) != 0)) { zend_error_noreturn(E_ERROR, "Cannot call abstract method %s::%s()", fbc->common.scope->name, fbc->common.function_name); CHECK_EXCEPTION(); ZEND_VM_NEXT_OPCODE(); /* Never reached */ } if (UNEXPECTED((fbc->common.fn_flags & ZEND_ACC_DEPRECATED) != 0)) { zend_error(E_DEPRECATED, "Function %s%s%s() is deprecated", fbc->common.scope ? fbc->common.scope->name : "", fbc->common.scope ? "::" : "", fbc->common.function_name); } } if (fbc->common.scope && !(fbc->common.fn_flags & ZEND_ACC_STATIC) && !EX(object)) { if (fbc->common.fn_flags & ZEND_ACC_ALLOW_STATIC) { /* FIXME: output identifiers properly */ zend_error(E_STRICT, "Non-static method %s::%s() should not be called statically", fbc->common.scope->name, fbc->common.function_name); } else { /* FIXME: output identifiers properly */ /* An internal function assumes $this is present and won't check that. So PHP would crash by allowing the call. */ zend_error_noreturn(E_ERROR, "Non-static method %s::%s() cannot be called statically", fbc->common.scope->name, fbc->common.function_name); } } 

小切手の数をご覧ください。 どうぞ

 if (fbc->type == ZEND_USER_FUNCTION || fbc->common.scope) { should_change_scope = 1; EX(current_this) = EG(This); EX(current_scope) = EG(scope); EX(current_called_scope) = EG(called_scope); EG(This) = EX(object); EG(scope) = (fbc->type == ZEND_USER_FUNCTION || !EX(object)) ? fbc->common.scope : NULL; EG(called_scope) = EX(call)->called_scope; } 

関数の各本体には、変数に対する独自のスコープがあることがわかっています。 エンジンは、機能コードを呼び出す前に可視性テーブルを切り替えます。そのため、変数を要求すると、対応するテーブルで検出されます。 また、関数とメソッドは本質的に同じものであるため、 $ thisポインターをメソッドにバインドする方法について読むことができます。

 if (fbc->type == ZEND_INTERNAL_FUNCTION) { 

上で述べたように、内部関数（Cの一部）には異なる実行パスがあり、ユーザー定義関数とは異なります。 通常、ユーザー定義の機能とは言えない内部機能についてエンジンに通知できるため、より短く最適化されています。

 fbc->internal_function.handler(opline->extended_value, ret->var.ptr, (fbc->common.fn_flags & ZEND_ACC_RETURN_REFERENCE) ? &ret->var.ptr : NULL, EX(object), RETURN_VALUE_USED(opline) TSRMLS_CC); 

上記の行は、内部関数ハンドラーを呼び出します。 strlen（）に関する例の場合、この行はコードを呼び出します。

 /* PHP's strlen() source code */ ZEND_FUNCTION(strlen) { char *s1; int s1_len; if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s", &s1, &s1_len) == FAILURE) { return; } RETVAL_LONG(s1_len); } 

strlen（）は何をしますか？ zend_parse_parameters（）を使用して、スタックから引数を取得します。 これは「遅い」関数です。スタックを上げ、引数を関数が期待する型（この場合は文字列）に変換する必要があるためです。 したがって、 strlen（）のスタックに何を渡しても、引数の変換が必要になる場合があり、これはパフォーマンスの面で最も簡単なプロセスではありません。 ソースコードzend_parse_parameters（）は、関数のスタックフレームから引数を取得する際にプロセッサが実行しなければならない操作の数の良いアイデアを提供します。

次のステップに進みます。 関数の本体コードを実行しただけで、今度は「整理」する必要があります。 スコープを復元することから始めましょう：

 if (should_change_scope) { if (EG(This)) { if (UNEXPECTED(EG(exception) != NULL) && EX(call)->is_ctor_call) { if (EX(call)->is_ctor_result_used) { Z_DELREF_P(EG(This)); } if (Z_REFCOUNT_P(EG(This)) == 1) { zend_object_store_ctor_failed(EG(This) TSRMLS_CC); } } zval_ptr_dtor(&EG(This)); } EG(This) = EX(current_this); EG(scope) = EX(current_scope); EG(called_scope) = EX(current_called_scope); } 

次に、スタックをクリアします。

 zend_vm_stack_clear_multiple(1 TSRMLS_CC); 

最後に、関数の実行中にいくつかの例外が発生した場合、仮想マシンをこの例外のcatchブロックに誘導する必要があります。

 if (UNEXPECTED(EG(exception) != NULL)) { zend_throw_exception_internal(NULL TSRMLS_CC); if (RETURN_VALUE_USED(opline) && EX_T(opline->result.var).var.ptr) { zval_ptr_dtor(&EX_T(opline->result.var).var.ptr); } HANDLE_EXCEPTION(); } 

PHP関数呼び出しについて

これで、コンピューターが「非常に小さく単純な」 strlen（）関数の呼び出しに費やす時間を想像できます。 また、複数回呼び出されるため、この時間を、たとえば25,000倍に増やします。 これが、マイクロ秒とミリ秒がフル秒に変わる方法です... PHP関数の各呼び出し中に、最も重要な指示のみを示したことに注意してください。 その後、さらに興味深いことが起こります。 また、 strlen（）の場合、「有用な作業」を実行するのは1行のみであり、関数呼び出しを大量に準備するための付随する手順はコードの「有用な」部分よりも大きいことに注意してください。 ただし、ほとんどの場合、ネイティブ関数コードは「補助」エンジンコードよりもパフォーマンスに影響します。

PHP 7の関数呼び出しに関連するPHPコードの一部は、パフォーマンスを改善するために再設計されました。 ただし、これは終わりにはほど遠いものであり、PHPのソースコードは新しいリリースごとに複数回最適化されます。 古いバージョンは忘れられず、関数呼び出しは5.3から5.5のバージョンで最適化されました。 たとえば、バージョン5.4から5.5では、互換性を維持しながらスタックフレームを計算および作成する方法が変更されました。 興味深いことに、ランタイムモジュールの変更と、 バージョン5.5で作成された関数の呼び出し方法と5.4を比較できます。

私は強調したい：上記のすべてはPHPが悪いことを意味するものではありません。 この言語は20年間開発されており、多くの非常に才能のあるプログラマーがソースコードに取り組んできました。 この期間、何度も処理され、最適化および改善されました。 これは、今日PHPを使用し、さまざまなプロジェクトで優れた全体的なパフォーマンスを発揮するという事実によって証明されています。

isset（）はどうですか？

これは関数ではなく、括弧は必ずしも「関数呼び出し」を意味するわけではありません。 isset（）は 、Zend仮想マシンの特別なオペコード（ISSET_ISEMPTY）に含まれています。これは、関数呼び出しを開始せず、関連する遅延の影響を受けません。 isset（）はいくつかのタイプのパラメーターを使用できるため、Zend仮想マシンのコードは非常に長くなります。 ただし、オフセットパラメータに関連する部分のみを残すと、次のような結果になります。

 ZEND_VM_HELPER_EX(zend_isset_isempty_dim_prop_obj_handler, VAR|UNUSED|CV, CONST|TMP|VAR|CV, int prop_dim) { USE_OPLINE zend_free_op free_op1, free_op2; zval *container; zval **value = NULL; int result = 0; ulong hval; zval *offset; SAVE_OPLINE(); container = GET_OP1_OBJ_ZVAL_PTR(BP_VAR_IS); offset = GET_OP2_ZVAL_PTR(BP_VAR_R); /* ... code pruned ... */ } else if (Z_TYPE_P(container) == IS_STRING && !prop_dim) { /* string offsets */ zval tmp; /* ... code pruned ... */ if (Z_TYPE_P(offset) == IS_LONG) { /* we passed an integer as offset */ if (opline->extended_value & ZEND_ISSET) { if (offset->value.lval >= 0 && offset->value.lval < Z_STRLEN_P(container)) { result = 1; } } else /* if (opline->extended_value & ZEND_ISEMPTY) */ { if (offset->value.lval >= 0 && offset->value.lval < Z_STRLEN_P(container) && Z_STRVAL_P(container)[offset->value.lval] != '0') { result = 1; } } } FREE_OP2(); } else { FREE_OP2(); } Z_TYPE(EX_T(opline->result.var).tmp_var) = IS_BOOL; if (opline->extended_value & ZEND_ISSET) { Z_LVAL(EX_T(opline->result.var).tmp_var) = result; } else { Z_LVAL(EX_T(opline->result.var).tmp_var) = !result; } FREE_OP1_VAR_PTR(); CHECK_EXCEPTION(); ZEND_VM_NEXT_OPCODE(); } 

多数の決定点を削除する場合（コンストラクトの場合 ）、「メイン」計算アルゴリズムは次のように表現できます。

 if (offset->value.lval >= 0 && offset->value.lval < Z_STRLEN_P(container)) 

オフセットがゼロより大きく（ isset（$ a [-42]）を意味しない）、厳密に行の長さより短い場合、結果は1と見なされます。その後、演算の結果はブール値TRUEになります。 長さの計算について心配する必要はありません。Z_STRLEN_P（コンテナ）は何も計算しません。 PHPはすでに文字列の長さを知っていることに注意してください。 Z_STRLEN_P（コンテナ）は 、この値をメモリに読み込むだけで、プロセッサリソースをほとんど消費しません。

これで、文字列オフセットの使用に関して、 strlen（）呼び出しの処理にはisset（）よりも多くの計算リソースが必要になる理由がわかりました。 後者は実質的に「簡単」です。 多数の条件付きifステートメントを恐れないでください;これはCコードの最も難しい部分ではありません。 さらに、Cコンパイラを使用して最適化できます。 ハンドラコードisset（）は、後で取得するために、ハッシュテーブルを調べず、複雑なチェックを実行せず、スタックフレームの1つにポインタを割り当てません。 このコードは、一般的な関数呼び出しコードよりもはるかに軽量であり、メモリへのアクセス頻度ははるかに低くなります（これが最も重要なポイントです）。 また、このような行の複数の実行をループすると、パフォーマンスが大幅に向上します。 もちろん、 strlen（）とisset（）の1回の反復の結果はそれほど変わりません-約5ミリ秒です。 しかし、50,000回の反復を実行すると...

また、 isset（）とempty（）の ソースコード はほぼ同じであることに注意してください。 行オフセットの場合、 空の（）は、行の最初の文字が0でない場合、追加の読み取りだけがisset （）と異なります。empty （）およびisset（）コードはほぼ同じであるため、 empty（）は同じように表示されますisset（）としてのパフォーマンス（両方が同じパラメーターで使用される場合）。

OPCacheがどのように役立つか

要するに、何もありません。

OPCacheはコードを最適化します。 これはプレゼンテーションで見つけることができます 。 strlen（）がisset（）に切り替わる最適化パスを追加することは可能かどうかとよく尋ねられます。 いいえ、これは不可能です。

OPCache最適化パスは、共有メモリに配置される前にOPArrayに実装されます。 これは実行時ではなくコンパイル時に発生します。 コンパイル時にstrlen（）に渡される変数が文字列であることをどのようにして知ることができますか？ これはPHPの既知の問題であり、HHVM / Hackで部分的に解決されています。 PHPで厳密な型付けを使用して変数を記述した場合、コンパイラのパス中に、（仮想マシンのように）はるかに多くのものを最適化できます。 PHPは動的言語であるため、コンパイル時にはほとんど何もわかりません。 OPCacheは、コンパイルが開始された時点で知られている静的なもののみを最適化できます。 たとえば、これは：

 if (strlen("foo") > 8) { /* do domething */ } else { /* do something else */ } 

コンパイル時には、文字列「foo」の長さが8以下であることがわかっているため、すべてのオペコードif（）を破棄し、if構造からelse部分のみを残すことができます。

 if (strlen($a) > 8) { /* do domething */ } else { /* do something else */ } 

しかし、 $ aとは何ですか？ 存在しますか？ これは文字列ですか？ オプティマイザーが合格するまで、これらすべての質問に答えることはできません。これは、仮想マシンの実行モジュールのタスクです。 コンパイル時に抽象構造を処理します。必要なメモリのタイプと量は実行時にわかります。

OPCacheは多くのことを最適化しますが、PHPの性質により、すべてを最適化することはできません。 , Java . , PHP . read-only:

 class Foo { public read-only $a = "foo"; } 

, . , $a . , , - , OPCache. , , OPCache , , .

, - . . Blackfire , , . , . , . , , , , .

: PHP , . PHP- — , , . . , , . , . PHP , foreach() , opcode. while for , .

, , , - .

 phpversion() => use the PHP_VERSION constant php_uname() => use the PHP_OS constant php_sapi_name() => use the PHP_SAPI constant time() => read $_SERVER['REQUEST_TIME'] session_id() => use the SID constant 

, .

, , :

 function foo() { bar(); } 

:

 function foo() { call_user_func_array('bar', func_get_args()); } 

, , - - - . , .

, . .

Blackfire , . ( GUI ): , , , / , , , foreach() .. など

, . , - . PHP ORM, , HTTP- . , . , : Java, Go , , — C/C++ (Java Go ).