[解決済み] 最適化はいつから始まるのか？

質問

Knuthが言ったように。

小さな効率は忘れるべきで、97％くらいはそうです：早すぎる最適化は諸悪の根源です。

これは、Stack Overflow の回答で、「最も効率的なループ メカニズムはどれか」、「SQL 最適化テクニックは何か」といった質問に対してよく出てくるものです ( など ). これらの最適化のヒントとなる質問に対する標準的な回答は、まずコードをプロファイルして問題があるかどうかを確認し、問題がない場合は新しいテクニックは必要ないというものです。

私の質問は、特定のテクニックが異なっていても、特に不明瞭または難読化されていない場合、それは本当に時期尚早の最適化と考えられるのでしょうか？

という Randall Hyde 氏の関連記事を紹介します。 早すぎる最適化の誤謬 .

どのように解決するのですか？

Don Knuth が始めた リテラート・プログラミング 運動は、彼が コンピュータコードの最も重要な機能は、プログラマの意図を人間の読者に伝えることである。 . パフォーマンスの名の下にコードを理解しにくくするようなコーディングのやり方は、時期尚早の最適化です。

最適化の名の下に導入されたある種のイディオムは、非常に一般的になっており 誰もがそれを理解する となり 期待される になったのであって、時期尚早ではない。 例としては、以下のようなものがあります。

• 使用方法 ポインタ演算 のようなイディオムの使用を含む、Cにおける

  for (p = q; p < lim; p++)
  
  

• グローバル変数のローカル変数への再バインド のように、Luaでは

  local table, io, string, math
      = table, io, string, math
  
  

そんな慣用句を超えて 危険を顧みず近道をする .

すべての最適化は時期尚早です。

• プログラムが遅すぎる (多くの人がこの部分を忘れています)。

• あなたが持っている 測定 (プロファイルまたは類似の) を示す 最適化によって状況が改善される可能性がある .

(メモリに最適化することも許されます)。

質問に対する直接的な回答です。

• もし、あなたの"different"テクニックが プログラムを理解するのが難しくなる であれば それは時期尚早の最適化である .

EDIT : コメントを受けて 挿入ソートのような単純なアルゴリズムの代わりにクイックソートを使うことで の別の例です。 誰もが理解し、期待するイディオムです。 . (ライブラリのソートルーチンを使う代わりに自分自身のソートルーチンを書くのであれば、あなたが 非常に な理由があることを望みます)。