PHP7とHHVMの性能を詳しく紹介（写真と文章）

PHP言語ランキングの推移

「TIOBEプログラミング言語ランキング」によると（このリストには統計手法に制限がありますが、それでも良い参考資料です）、2010年にはPHPが最高位でした。世界のプログラマー数 言語の中で第 3 位。 PHP 言語は、PC インターネット時代の Web 分野で最も強力な言語であることがわかります。                                                                   

かつて、PHP プログラマーの間で次のようなジョークが広まりました。 PHP プログラマー: PHP は世界で最高の言語です! 锅锅

某 ： ： ： ： ： ： ：

、行こう！ PHP プログラマー: 今日はだめです。PHP が最高の言語に違いないことを彼らに説得しなければなりません。

さて、本題に戻りましょう。言語自体が良いとか悪いとかではなく、それが使用されるシナリオでさまざまな問題を解決するだけです。モバイルインターネットの登場により、インターネット時代は短期間で急速に進んでいます。 4 年以上にわたり、モバイル テクノロジーの開発は世界を席巻しました。同時にさまざまな言語が台頭しており、かつて栄華を誇ったPHPはオリジナルのプログラミング言語リスト（2014年12月リスト）から6位に転落しました。 1つ）。その結果、PHPを悪く言う声が次々と出た。

                                                                   

しかし、ニアオ兄弟（フイ・シンチェン、PHP言語開発者の一人）は、2014年のQconでデータを共有しました。世界の上位100万のWebサイトのうち、81.3%が使用しています 使用されている Web サーバー スクリプト言語は PHP で、2013 年の同時期には 78.3% でした。つまり、PHP は Web サービスとしては減っていませんが、モバイル インターネットの波の中で大きく増加しています。 したがって、他の言語テクノロジの適用は希薄化されます。

最近、PHP7 と HHVM のパフォーマンス比較が話題になり、どちらが PHP のパフォーマンス向上の将来になるかについて誰もが議論し、注目しています。

HHVM (HipHop Virtual Machine) の起源

HHVM は、JIT コンパイルとその他のテクノロジーを使用して、PHP コードの実行パフォーマンスを大幅に向上させるオープンソースの PHP 仮想マシンです。現在のバージョンのネイティブ PHP コードの実行パフォーマンスは 5 ～ 10 倍向上する可能性があると噂されています。

HHVM は Facebook から生まれました。Facebook の初期のコードの多くは PHP を使用して開発されましたが、ビジネスの急速な発展に伴い、PHP が実装されました。 業務効率がますます明確な問題になってきています。実行効率を最適化するために、Facebook は 2008 年に PHP 実行エンジンである HipHop を使用し始めました。 大量の Facebook PHP コードを次のように変換します。                             C++ を使用すると、パフォーマンスが向上し、リソースが節約されます。 HipHop を使用した PHP コードのパフォーマンスは数倍向上しました。その後、Facebook はヒップホップ プラットフォームをオープンソース化し、徐々に現在のプラットフォームに発展させました。 HHVM。

🎜🎜1. PHP が遅いのはなぜですか? 🎜🎜 🎜

PHP は C/C++ レベルの言語よりも遅いです。実際、PHP 言語は元々、コンピューティング集約型のアプリケーション シナリオを解決するように設計されたものではありません。 PHP は開発効率を高めるために実行効率を犠牲にしていることが大まかに理解できます。

PHP の大きな特徴は弱い型の機能であることはわかっています。つまり、変数を自由に定義し、それをさまざまな種類のデータに自由に割り当てることができます。 int 整数値を例として、C 言語では:

int num = 200;//通常是4字节

ただし、PHP が同じ変数を定義する場合、実際に対応するストレージ構造は次のようになります:

この 構造 C の変数よりもはるかに多くのメモリを占有します。PHP では次のように定義されています。 。 PHP プログラマの変数タイプ「侵入」と互換性を持たせるために、PHP は次のことを行います。 開発者にとっては親切ですが、実行エンジンにとっては残酷です。単一変数のメモリ消費量はまだ明らかではないかもしれませんが、PHP の array

などが使用されると、複雑さは飛躍的に増加します (配列の実装は HashTable です)。次に、Zend エンジンが実行されると、これらの PHP コードはオペコード (PHP の中間バイトコード、形式はアセンブリに似ています) にコンパイルされ、Zend エンジンはそれを 1 行ずつコンパイルします。 説明と実行。

strings

の接続操作にしても、配列等の単純な変更にしても、ほぼ「PHPプログラマの一言でZendエンジンが壊れる」のリズムです。したがって、同じ操作を行う場合、PHP は C よりも CPU やメモリなどのシステム リソースをより多く消費します。また、自動メモリリサイクルや変数の型判定などもあり、システムリソースの消費量が増加します。

たとえば、純粋な PHP に実装されているクイック ソート関数とネイティブ ソート関数を使用して、時間のかかる比較を行うために 10,000 個の整数を並べ替えた結果は次のとおりです。 ネイティブ ソートには 3.44 ミリ秒かかりますが、私たちが独自に実装した

PHP 関数

sort では 68.79 ミリ秒かかります MS。両者の間には実行効率に大きな差があることがわかりました。私のテスト方法は、PHP スクリプト全体の開始から終了までの時間ではなく、関数の実行前後の時間間隔を計算することです。起動およびシャットダウンする PHP スクリプトも プロセス自体には一連の初期化とクリーンアップ作業があり、これにも多くの時間がかかります。                                                                                                                                                                                                                                                                                                                                                              

通常、PHPの実行効率のランキングは次のとおりです:

                 

最も速いのは、PHP 言語の一部である PHP 言語構造 (isset、echo など) です (これらは関数ではありません)。

そして、より高速なものは、PHP のネイティブ関数と拡張関数です。 PHP 拡張機能は Zend API に基づいており、C で関数を実装しており、その実行効率は C++/Java と同程度です。

本当に遅いのは、PHP を通じて自分で作成したコードと関数です。たとえば、純粋な PHP で実装された比較的重いフレームワークを使用すると、フレームワーク自体に多くのモジュールが含まれるため、言語レベルでの実行効率が明らかに低下し、より多くのメモリを占有することになります。 (国産のYafフレームワークを拡張して実装しているため、純粋なPHPで書かれたフレームワークよりも実行効率が大幅に高速です)

                                                                                                                                                              

通常の状況では、特に Web システムのトラフィックが比較的大きいシナリオでは、PHP を使用して複雑な論理計算関数を実装することはお勧めしません。したがって、PHP プログラマーは次のことを行う必要があります。 PHP のさまざまなネイティブ関数とさまざまな拡張機能を比較的幅広く理解し、特定の関数実装シナリオでは、複雑なソリューションを自分で作成するのではなく、よりネイティブなソリューション (ネイティブインターフェース
または拡張機能) を探します。 このタイプの機能を実装するための PHP コード。

十分な PHP 拡張機能の開発能力がある場合は、この種のビジネス関数を PHP 拡張機能として書き直すと、コードの実行効率も大幅に向上します。これは非常に優れた方法であり、PHP の最適化でも広く使用されています。ただし、自分で作成した PHP ビジネス開発の欠点も明らかです:

拡張開発には時間がかかり、要件が変更された場合の修正が複雑になる可能性があります。不十分な記述は Web サービスの安定性に影響を与える可能性があります。 (たとえば、Apache のワーカー モードでは、マルチスレッド シナリオでハングすると、同じプロセス内の他の通常のサブスレッドに影響します。マルチスレッド Web モードの場合、拡張機能の作成でもスレッド セーフをサポートする必要があります。 )

PHP バージョンがアップグレードされると、拡張機能で追加の互換性作業が必要になる場合があります。

1. 人事異動後の維持費や引き継ぎ費も比較的高額です。実際、インターネットの第一線の企業では、C/C++ を使用してサービス サーバーを独立して作成し、PHP がソケットとサービス サーバーを介してビジネスを完了する一般的なソリューションが PHP の拡張を促進しません。ビジネスを完了するためのビジネス 処理は、PHP 自体をビジネスと結びつけません。

2. しかし、Web サービスのパフォーマンスのボトルネックのほとんどは、ネットワーク送信や他のサービス サーバー (MySQL など) に時間がかかることにあり、PHP の実行にかかる時間はごくわずかです。全体的に時間がかかるため、ビジネスの観点から見ると、その影響は明らかではないかもしれません。

3. 2. HHVM が PHP の実行パフォーマンスを向上させる方法

HHVM は、PHP の中間バイトコードを生成および実行するために Zend エンジンを置き換えることにより、PHP のパフォーマンスを向上させます (HHVM は独自の形式の中間バイトコード バイトを生成します) コード）、JIT を通じて実行されます（                            

時間

、ジャストインタイム コンパイルはソフトウェア最適化テクノロジであり、バイトコードが実行時にマシン コードにコンパイルされ、実行のためにマシン コードに変換されることを意味します。 Zend エンジンのデフォルトの方法では、まずオペコードにコンパイルしてから、それを 1 つずつコンパイルします。 実行では、通常、各命令は C 言語レベルの関数に対応します。多数の繰り返しオペコード (純粋な PHP で書かれたコードと関数) を生成すると、Zend はこれらの C コードを 1 つずつ複数回実行します。 コード。 JIT が行うことは、さらに一歩進んで、実行効率を向上させるために、繰り返し実行される多数のバイトコードを実行時にマシンコードにコンパイルすることです。通常、JIT をトリガーする条件は、コードまたは関数が 繰り返される電話。

                                                                        

通常の PHP コードでは、変数の型を固定できないため、型を決定するためのロジック コードを追加する必要があります。このような PHP コードは CPU の実行と最適化に役立ちません。 の。したがって、HHVM は通常、変数の型を固定して仮想化を容易にするために、Hack 記述法 (特定の機能と互換性を持たせるために追加された追加の技術コード) を備えた PHP コードを使用して「連携」する必要があります。 マシンがコンパイルされて実行されました。 PHP はすべての型を 1 つの形式で収容することを追求しますが、Hack は収容されるすべてのものを特定の型でマークできます。

PHPコードでのハック記述の例:

                                                                                   

上記の例では、主に変数の型を追加したPHPコードを記述しています。 Hackの書き方の大まかな方向性は、これまでの「動的」な書き方から、HHVMと連携する「

静的

」な書き方に変更することです。

HHVM はその高性能さから注目を集めており、一部の一流インターネット企業も追随して利用し始めています。純粋言語の実行パフォーマンス テストの結果から判断すると、HHVM は開発中の PHP7 バージョンよりもはるかに優れています。

しかし、具体的なビジネスシナリオの観点から見ると、WordPress オープンソースブログホームページをテストシナリオとして使用した結果では、HHVM と PHP7 の間のギャップはそれほど大きくありません。 、彼らの現在のギャップは明らかではありません。                                                                                      

しかし、すでに利用可能な技術的ソリューションから判断すると、PHP7 はまだ開発中です。現在の HHVM の方がわずかに優れています。ただし、HHVM の展開とアプリケーションにはいくつかの問題があります。

サービスの展開は比較的複雑で、一定のメンテナンス費用がかかります。

は PHP ネイティブ コードを完全にはサポートしていません。また、PHP 拡張機能も適切に互換性がある必要があります。

HHVM は新しい仮想マシンであるため、長時間実行するとメモリ リークが発生する可能性があります。 (第一線のインターネット企業がこの技術を適用すると、パッチを自ら再生することでメモリリークを解決するそうです。)
Hhvm は、結局のところ、まだある程度の時間がかかるオープンソースプロジェクトです。成長して成熟するまでの時間。

2. PHP7 のパフォーマンス革新

3. PHP が長い間批判されてきたパフォーマンスの問題は、このバージョンでは大幅に改善されます。このバージョンには途中の PHP6 というプロジェクトはなく、混乱を避けるためにほとんどの機能が 5.x バージョンで実装されたと言われています。 。 （何年も前に、PHP6 に関するものもありました。）1. PHP7 のメディア

確かに、PHP7 の正式バージョンは 2015 年になる可能性があります。 10月份才出版、不过テスト版は来年 6 月に公開され、その後 3 ～ 4 か月の品質保証が提供される予定です。

PHPコミュニティのプロジェクト計画は次のとおりです:

私たち私たちの

?他にも間違いなく他にも機能がありますが、まだ発表されていないだけです。以下は PHP コミュニティからのものです。PHP7 は開発中のプロジェクトであるため、以下は正確ではない可能性がありますが、参照することを妨げるものではありません。

1. PHPNG (PHP 次世代、次世代 PHP)、JIT を含む Zend 実行エンジン自体のさまざまなパフォーマンスの最適化が Zend に実装される場合があります Opcache コンポーネント内。

2. AST (抽象構文ツリー、抽象構文ツリー) は、インタープリターからオペコードを直接吐き出す方法を置き換えるために、PHP コンパイル プロセスにミドルウェアを導入するように設計されています。インタプリタとコンパイラを分離すると、多くのハック コードが削減され、同時に実装の理解と保守が容易になります。

3. 統一変数構文 (統一変数構文) は、内部的に一貫した完全な変数構文を導入し、PHP のパーサーがさまざまなタイプの変数をより完全にサポートできるようにします。変数 $$a など、いくつかの変数の使用法を調整する必要があります。

4. NaN、Infinity、5c699fe59dd7ce715253b736c25509d2> などの整数セマンティクス (整数セマンティクス) をサポートし、list() などの一貫性を修正します。

上記の機能の中で、最も期待されているのは、PHPng のパフォーマンスの最適化です。PHP コミュニティは、いくつかのパフォーマンス速度テスト データを公開しています。データの観点から見ると、PHPng 実行パフォーマンスはプロジェクト開始時に比べて2倍近くになりました。この結果はすでに非常に良好です。さらに、最も重要なことは、PHP7 の最適化計画がまだ完了していないことが多いということです。すべてが完了するまで待ちます、 より高性能な PHP7 が見られると思います。この速度測定データは、データの一部を傍受するPHPコミュニティ（wiki.php.net/phpng）からのものです。

簡単な翻訳:

                           

総合的なテスト速度が35%向上しました。

実際のアプリケーションシナリオでは、20%〜70%の速度向上があります(WordPressホームページでは60%の改善があります)

メモリ消費量の削減

最も一般的に使用されるサポートSAPIs

• リソース割り当てにバインドされたほとんどの PHP 拡張機能をサポート (69 が完了、6 が移行予定)

• HHVM3.3.0 に匹敵する実行速度を実現

•                            

• 2. PHPの弱い型論争

• PHP には物議を醸す機能が数多くありますが、言語バージョンのリリースと改善により、機能や機能に対する批判は減少し始めています。しかし、PHP の「弱い型」機能は明らかにより物議を醸しています。HHVM が Hack を通じて「弱い型」機能を直接「削除」したという事実から、HHVM が「弱い型」機能を好まないことがわかります。しかし、私たちの多くでは、 PHP プログラマーにとって、これは PHP の重要な利点の 1 つです。 PHP の変数は、カジュアルかつエレガントになるように設計されており、言語がよりシンプルになると思いませんか。

  実際、「弱い型付け」に対する批判は次のようなものです。                            

  通常、変数の型は最初から最後まで事前に定義されており、変数の型は固定されており、使用範囲も固定されています。
  PHP 変数
  1. に関しては、通常はその名前しか確認できず、ほとんどの型は事前定義できず、自由に変更できます。 (メモリ割り当ての管理は容易ではありません)
     弱い型の機能と互換性を持たせるために、PHP は型判定、
  型変換
  2. 、格納メソッドなどを含む互換性のあるコードを多数実装する必要があります。 、これにより言語の内部の複雑さが増加します。 (非効率な実行)
     変数の型は制御不可能であり、実行プロセス中に多数の「暗黙的な型変換」が行われ、予測不可能な結果が発生しやすいです。 (ここで、PHP の型変換は習得しなければならない点であることを強調する必要があります。さまざまな型を相互に変換すると、特に PHP を初めて使用する学生にとっては、多くの問題が発生する可能性があります)

  3.                            

  彼らは、これらは「見たものがそのまま得られる」という単純さとは一致しておらず、厳密な文法を持つ言語の方が効率的で「理解」しやすいと信じています。

  Javascript

  などの言語も、この問題に関するパフォーマンスが同じであるため、同様に批判されています。ただし、言語が最終的に大規模に使用されるためには、次のことが必要です。 それらには理由があります。 PHP が Web サービス開発で好まれるスクリプト言語になり、JavaScript が Web フロントエンド分野を直接的に支配するようになったのは偶然ではありません。 足は彼らに投票しました。プログラミング言語は人間と機械の架け橋であり、究極の追求は「誰もがプログラミングできるようにする」という壮大な目標を達成することです。

  言語開発の歴史を通して、0と1の機械語から始まり、アセンブリ言語、C言語、そして動的スクリプト言語PHPへと至りました。実行効率は指数関数的に減少しますが、学習閾値も指数関数的に減少します。 PHP 言語は、C のメモリ管理とポインタの複雑さを保護するだけでなく、変数型の複雑さもさらに保護します。プロジェクト開発の効率が向上し、学習の敷居が下がりますが、同時に実行パフォーマンスがある程度犠牲になります。そして、HHVM の Hack は変数の複雑さを再び導入する「原始への回帰」の感覚を与えます。もちろん、言語が異なれば、異なるシナリオで問題が解決されるため、一般化することはできません。

                                                                                     

  。どちらも優れたオープンソース プロジェクトであり、常に改善されています。 前進し、発展していく。現時点では、PHP7 の正式バージョンがリリースされるまでにはまだ長い時間がかかるため、パフォーマンス最適化ソリューションの現在の選択肢はもちろん HHVM です。でも、個人的にはもっと好きです PHP7 は PHP コードとの下位互換性が高いため、私は PHP7 について楽観的です。両者の性能に大きな差がない場合は、シンプルな方を選択します。

以上がPHP7とHHVMの性能を詳しく紹介（写真と文章）の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。