PHP コード解析 loss_PHP チュートリアルを効率的に最適化する方法

プログラマーは

に取り組んでおり、PHP 構文解析に費やされる損失が大部分を占めることがわかりました。valgrind を使用してその C 呼び出しを確認すると、時間の約 50% が次のことに費やされていることがわかります。レックスとヤック。これは、PHP コードをオペコードに変換する部分です。つまり、PHP コードの解析損失です。

この側面における PHP コード解析損失の最適化制限の目標は、1 回のアクセスで 1 つの PHP ファイルのみが実行され、このファイルにはこのプロセスに関係のないコードが含まれないことです。

理解しやすいコード構造とパフォーマンスのバランスをどう取るかが課題です

私たちの処理のアイデアは、smarty のようなコンパイル システムを通じて各ファイルへのアクセスをコンパイルすることです。shopex は MVC 構造であるため、コンパイルの粒度は高くなります。コントローラごとのメソッドです。プロセスファイルに対応します。

コントローラーが初めて呼び出されるとき、コントローラーはメソッドを通じて流れる各モデルメソッド、サブプロセスなどを監視し、最終的にそれを抽出してパブリックデータベース接続関数、設定ファイルなどと組み合わせます。単一の究極の PHP ファイル。
キャッシュの更新については、基本的にはバージョンアップのたびにバージョンアップを行います。キャッシュ統計ファイルの最終変更時刻をタッチするだけです。

その後、実装には 2 つの課題があります:

* 1 つはモデルの機能化と呼ばれるものです (この呼び方はクールで、仮想の死のようなものです)。それは、モデル層のオブジェクト特性を弱め、クラスを関数のコンテナに縮退させ、継承を減らし、これらのアプリケーションに過負荷をかけることです。
* 2 つ目は、独自のコンパイル エンジンを実装することです。

上記 2 つの最新の shopex485 は大きな進歩を遂げ、商品と注文の機能が分割されました。 PHP コード解析の喪失に対する 2 番目の解決策は、tramsy (smart+y) と呼ばれるパーサーを実装したことです。これは、多数のプラグインをコンパイル済みタイプに変更することを特徴としています。コンパイル済みプラグインの機能が強化され、コンパイル済みモディファイアープラグインの種類が追加されました。そして、変数の事前バインディングの概念を提案しました:

<ol class="dp-xml">
<li class="alt"><span><span>{if $</span><span class="attribute">var</span><span>=</span><span class="attribute-value">1</span><span>}  </span></span></li>
<li><span>yes  </span></li>
<li class="alt">
<span>{elseif $</span><span class="attribute">var</span><span>=</span><span class="attribute-value">2</span><span>}  </span>
</li>
<li><span>no  </span></li>
<li class="alt"><span>{else}  </span></li>
<li><span>what?  </span></li>
<li class="alt"><span>{/if} </span></li>
</ol>

ネイティブ Smarty の場合、生成されるコードは次のとおりです:

<ol class="dp-xml">
<li class="alt"><span><span>vars['var']==1){ </span><span class="tag">?></span><span> </span></span></li>
<li><span>yes  </span></li>
<li class="alt">
<span>vars['var']==2){ </span><span class="tag">?></span><span> </span>
</li>
<li><span>no  </span></li>
<li class="alt"><span>what? </span></li>
</ol>

tramsy の場合、プログラマは var が 1 でなければならないと予測します。そして、値が変更されたときにシステムがテンプレート キャッシュを自動的にクリアすることを確認し、それを「事前バインド変数」として設定することができます
そして、最終的に生成されるコードは次のとおりです:

いいえ

この設計により、コンパイルが大幅に削減されます2倍以上の結果が出ました。パフォーマンスが約 20% 向上し、PHP コードの解析ロスが大幅に最適化されました。

http://www.bkjia.com/PHPjc/446133.htmlwww.bkjia.comtru​​ehttp://www.bkjia.com/PHPjc/446133.html技術記事プログラマは、PHP の構文解析での損失が大部分を占めていることを発見しました。valgrind を使用してその C 呼び出しを確認すると、時間の約 50% が lexyacc に費やされていることがわかります。 ...