「時期尚早の最適化はすべての悪の根源である」という有名な声明は、ドナルドクヌースのペンに属しています。 残念ながら、このフレーズの本来の意味は長い間失われており、最近では言い訳としてのみ使用されており、プログラムの速度に対する主張を打ち消すことができます。
開発のどの段階でパフォーマンスに注意を払うべきですか？ 最適化はどの時点で時期尚早でなくなり、タイムリーになりますか？
一般的な意見は次のとおりです。ほとんどのコードをすでに記述している場合にのみパフォーマンスに注意してください。 プロファイラーを起動し、コード内のすべての問題領域を見つけて最適化します。 このアプローチを使用すると、結果（どうやら！）は、最初からパフォーマンスについて考えていた場合と同じになります。 なじみのある言葉でしょ？
業界で1年以上働いており、12を超えるプロジェクトを完了しているので、自信を持って言うことができます。これは完全にナンセンスです。 実際、すべてがまったく異なる方法で行われます。
これは、理想的な仮想プログラムで実行した場合にプロファイラーが表示する必要があるものです。理想的なプログラムは、高いパフォーマンス要件を考慮して最初から作成されました。 その中のすべてのメソッドは同等に迅速に実行され、パフォーマンスが浪費される場所はまったくありません。
「時期尚早の最適化にノーと言ってください！」というスローガンで書かれたプロジェクトにプロファイラーを設定すると、そのようなものが表示されることが期待されます。
実際には、これは決して起こりません。 いいえ、はい 。 当初から生産性を最優先していなかった場合、どこにでも効果のないソリューションが出現し、プロジェクト内のすべての平方キロバイトのコードに感染します。 巨大な配列を愚かに繰り返すことができるのに、なぜハッシュテーブルを使用するのですか？ くしゃみごとにLINQを使用して、大量の冗長データを絶えず除外できるのに、なぜSQLクエリを書くのですか？
ほとんどの場合、プロファイラーはこれを描画します。
この状況は非常に典型的です。 プロジェクトの最初の日からパフォーマンスについて考えていなかったなら、信じてください、あなたは最後までそれについて覚えていません。 「最も効率の悪い機能を見つけて、すぐに最適化し、すぐにすべてが機能するようになります！」などの希望で安心する必要はありません。 このアプローチでは、すべての機能が感染し、標的治療は役に立ちません。 ムーアの法則もあなたの助けにはなりません。シングルプロセッサコアのパフォーマンスは数年間変化していません。 9人の女性が1か月以内に出産することはできません。 あなたの場合、遅かれ早かれ優れたハードウェアがプログラムを迅速に動作させることを夢見、物理的な限界に突入するでしょう。
人生の例が必要ですか？ お願いします。 SugarCRMビジネスポータルの1ページの最小レンダリング時間は、最高のハードウェアであっても約100ミリ秒です。 Webアプリケーションの世界では、この状況は誰にも迷惑をかけません（Webページのすべてのクリックが数秒間処理されるという事実に誰もが長い間慣れていました）が、状況によっては、短い応答時間が一部のWebサービスにとって深刻になっています競争上の優位性。 私はRdioインターネットラジオが大好きですが、ページ切り替えの間に2番目の遅延が生じないアナログを見つけた場合は、すぐに切り替えます。
リリース前にすべてのバグを修正することはめったにありません。 同様に、すべてのパフォーマンスの問題を短時間で解決することはできません。 この状況は、本来これを目的としていないアルゴリズムを並列化しようとすることに非常に似ています。原則としては可能ですが、ほとんどすべてをゼロから書き直す必要があります。
上記を要約すると、Knutが表明した有用な原則は、ばかげたことになりました。 誰かが時期尚早の最適化について話すとき、彼はほとんど確実にKnuthが念頭に置いていたことをまったく意味しません。