多くのフレームワークはspl_autoload_register()、動的にクラスをロードするために使用します (つまり、コントローラーとモデル)。自動ロードとオペコード キャッシングの問題に関する投稿がいくつかあります。特に1つの投稿には、@RasmusがAPCをオペコードキャッシュとして利用している人々にとって不快であることが証明されている多くのステートメントを作成することを参照する@cletusによる応答があります。
オペコード キャッシュのパフォーマンスに影響を与えないオートローディングの代替案についての議論はないようです。
自動ロードされたクラスがバイトコードキャッシュに追加されないという事実を回避する方法はありますか?
そうでない場合、キャッシュされるクラスを動的にロードするための代替方法はありますか?
このトピックについてはまだ混乱があるようですが、ほとんどの場合、使いやすさとパフォーマンスの問題に帰着します。
読むべき良いメーリング リスト スレッドは、Zend Frameworks メーリング リストの次のスレッドです。
http://n4.nabble.com/ZF-and-Autoloading-td640085i20.html
まだ定義されていないクラスから継承する場合、それを定義するためにオートロードに依存する可能性があり（インクルードにも依存する可能性があります）、実際にはオートロード機能の存在により、そのような使用が促進される可能性があるため、相関関係はここにあります継承。しかし、これはオートロードが問題を引き起こすわけではありません (トラブルの例については、ブログの Ramus の「オートロードだけではない」を参照してください)。したがって、正しい言い回しは、「オートロードに依存する傾向がある人は、コンパイル時のバインディングに逆らうコードも使用する傾向がある」です。もちろん、これはオートロード違反とは見なされず、オートロードを回避するだけでは少しは役に立ちません。コンパイル時のバインディングが発生するようにコードを書き直す必要もあります。また、「new」で autoload を使用することとは関係ありませんが、
上記の影響による速度低下 (つまり、コンパイル時のバインディングの欠如) については、コードは確かに少し遅くなり、そのようなコードは、あいまいなケースでオペコード キャッシュに問題を引き起こす可能性があります (オートロードのケースではありませんが、クラスが条件内で定義されている場合、または神が禁じている場合、条件に応じて異なる定義が作成されます) - しかし、autoload 自体を使用することとはほとんど関係ありません。しかし、スローダウンの量は人々によって非常に誇張されているようです - それは何もありません (そして、明確にするために繰り返します - 何もありません) ディスク操作とコンパイル段階がないため、オペコード キャッシュによって得られるパフォーマンス上の利点と比較してください。おそらく、かなりの速度低下を示す人工的なベンチマークを構成することはできますが、実際のアプリケーションが気付くことさえないと思います。
ソース: http://n4.nabble.com/ZF-and-Autoloading-td640085i20.html#a640092