PHP や JavaScript などのインタープリター型プログラミング言語では、手続き型アプローチよりもオブジェクト指向アプローチを採用すると、どのような影響がありますか?
特に私が探しているのは、Web アプリケーションを作成し、速度だけでなく保守性も最適化するために、手続き型アプローチとオブジェクト指向アプローチのどちらかを選択する際に考慮すべき事項のチェックリストです。これをさらに調査する記事を知っている場合は、引用された研究とテストケースも役立ちます。
結論: インタプリタ言語で OO と手続き型を使用した場合、実際にパフォーマンスへの影響が (あるとすれば) どのくらい大きいのでしょうか?
多分私は頭がおかしいですが、このような場合に解釈言語を使用して速度を心配することは、小屋をペイントする色を見つけようとするようなものです。この種の最適化は完全に時期尚早であるという考えにさえ入り込まないようにしましょう。
「保守性」と言ったら、頭に釘を打ちます。私は、最も生産的で最も保守しやすいアプローチを選択します。後で速度が必要になった場合、それは、インタプリタ言語内で手続き型コーディングパラダイムとオブジェクト指向コーディングパラダイムを切り替えることから生じるものではありません。
残念ながら、私もテストを行いました。私は速度をテストしましたが、ほぼ同じですが、PHP で memory_get_usage() を取得してメモリ使用量をテストすると、OOP 側で圧倒的に大きな数値が見られました。
OOP の 116,576 バイトから手続き型の 18,856 バイト。「ハードが安い」とは分かっていますが、是非！使用量が 1,000% 増加？申し訳ありませんが、それは最適ではありません。非常に多くのユーザーが一度に Web サイトにアクセスすると、RAM が燃え尽きるか、使い果たされることは間違いありません。私が間違っている？
結論：いいえ、解釈のオーバーヘッドがメソッドディスパッチのオーバーヘッドを圧倒するためです。
私の経験では、負荷の高いサイトは、手続き型よりも OOP コードの方がはるかに簡単に動かなくなり、応答しなくなります。理由は簡単に理解できます。
OOP では、手続き型コードよりも多くのメモリ割り当て (MALLOC) と、メモリ内で実行するためのより多くの操作が必要です。タスクを実行するには、より多くの CPU 時間が必要です。これは本質的に「オーバーヘッド」であり、手続き型コードにラップされ、特にデータベース操作を実行するときに、それを実行するために CPU の負担が増えます。
多くのプログラマーは、OOP の便利さを好み、単純なインターフェイスの背後に小さなブラック ボックスを作成します。ただし、ユーザーの負荷が高い状態で応答に永遠にかかっていたサイトを復活させることで、私は十分な報酬を得ています. OOP を取り除き、単純な手続き型関数に置き換えることで、大きな違いが生まれました。
サイトが非常に混雑することが予想されない場合は、必ず OOP を使用してください。トラフィックの多いシステムを構築している場合は、処理からすべての CPU サイクルを取り除き、出力から可能な限りすべてのバイトを取り除きたいと思うでしょう。
インタプリタ言語を使用している場合、違いは関係ありません。パフォーマンスが問題になる場合は、インタプリタ言語を使用しないでください。どちらもほぼ同じように動作します。
あなたのパフォーマンスは、言語ではなく、実装によって特徴付けられます。最も遅い言語を使用しても、スケーリングするように設計する限り、世界最大のサイトにスケーリングできます。
最適化の最初のルールを覚えておいてください。
しないでください。
:)
私が管理しているウェブサイトで、Python でこのような小さなテストを実際に行ったところ、手続き型のアプローチが 1 万分の 1 秒程度で勝っており、速度はほぼ同等であることがわかりましたが、OO コードは非常に重要でした。クリーナー 私はエクササイズを 1 回以上続けませんでした。
本当に、それは問題ではありません（とにかく私の経験では）。