PHPオペコードキャッシング/ Zendアクセラレーションとinclude_onceとrequire_once

Question

私は、PHPベースのアプリケーションのオペコードキャッシング/ Zendアクセラレーション（これらは常に同じものだと思っていました）を検討している同僚がいます。彼のベンチマークは、（大）クラスライブラリをrequire_onceに含めた場合、パフォーマンス上の利点は見られないことを示しているように見えますが、include_onceを使用するとパフォーマンス上の利点があります。

これは私たち二人にとって不快な臭いがしますが、私はベンチマークの方法論を自分でチェックする時間がなく、同僚は私よりも魚の臭いに寛容です。 ：）

このようなことに遭遇した人はいますか？そうでない場合は、include_onceからrequire_onceに切り替えることで、パフォーマンスの外観を引き起こす可能性のある他のことについての考えがありますか？

Answer 1

最初に、両方の呼び出し（require_onceおよびinclude_once）は、ファイルが以前に含まれていないかどうかを再確認します。

したがって、両者がこれを達成する方法は、利用可能なすべてのパスでファイルを検索し、本質的に以前にミックスに含まれていないかどうかを確認することなどです。

バックグラウンドでは、すべての異なるオプション（複数のinclude_pathなど）を評価し、この短縮形から realpath を作成することで一意の識別子を作成します。パスは1つだけで、2つではありません。

これはすでに地球上で最速のプロセスではなく、一般にPHPの各リクエストで発生します。次に、 realpath と呼ばれるものを作成するときに、statである別の高価な操作を追加します（realpath、 realpath（）はファイルが存在するかどうかを確認します。

間違っている場合は修正しますが、APCには特にこの場合の最適化があります。

だからとにかく-require_onceとinclude_onceの違いについて、つまりrequire_onceはファイルを（低レベル解析エラーなどのために）評価するそれが含まれています。これは追加のチェックであり、解析エラーがインクルードに潜入できないほど十分なQAがある場合は削除できます。

別の方法を見つけるのは難しいです。 ：-）

（考慮事項：require_onceで開発し、デプロイ時にすべての呼び出しをinclude_onceに置き換えることができます。）

オペコードキャッシュについては、 APC をお勧めします。以前にstackoverflowで議論されました。個人的に、私はしばらく使用しています（3つのフロントエンドと1つのバックエンドで1日およそ10万人の訪問者を処理しています）。 APCはrequire_once / include_onceの狂気にも最適化されています。

かなりクールな副作用は、APCを使用するとPHP変数をメモリに保存できることです-一種の永続化など。

いくつかの追加のポインター：

1. 多くの人が、 __autoload でアプリケーションを高速化すると主張しています。
2. オペコードキャッシュを使用して、条件付きrequire_once / include_onceを回避します（ループや制御フローなど）。
3. include_またはrequire_onceの/absolute/path/to/file.phpはinclude_pathに依存するよりも速いと言う人もいます。
4. include_path内のパスの順序も重要です。

役立つこと。

Answer 2

十分に深く見ていなかったので、何も保証できませんが、はい、2つの速度に違いがあります。ただし、require_onceではなくinclude_onceに移行するほど重要なものではありませんでした。

私は常に、require_onceが水中でより多くの作業を行う必要があるため、違いがあると考えていました。少なくとも1つの潜在的なエラーを準備して処理し、必要なファイルが存在しない場合はさらに多くのエラーを発生させます。