関数のBig O実行時間を変更するときに何と呼びますか[クローズ]

O(n^2)時間内にデータベースをソートする関数があるとしましょう。私はそれをリファクタリングしてO(n log(n))時間内に実行したいので、戻り値と入力を同等に保ちながら、操作の基本的な方法を変更します。

このリファクタリングアクティビティを何と呼びますか？

「高速化」は、アルゴリズムを実行する際の大きなO速度を変更せずにアルゴリズムを高速化できるため、あまり適切ではないようです。

「単純化」も正しくないようです。

このアクティビティを何と呼びますか？

更新

私が見つけた最良の答えは、漸近的な時間の複雑さを減らすことです。

これは通常「パフォーマンス最適化」と呼ばれますが、「リファクタリング」とは呼びません。この用語は通常、目に見える動作を変更しないコードの変更を指すからです。そして、Big-Oの変更は、間違いなく私が目に見える変更と呼ぶものです。

そうすることで、操作の基本的な方法を変更します

この場合、最適化はその関数の書き換えです。「Big-O」を変更したとしても、必ずしもすべての最適化が書き直しであるとは限りません。そのような改善を達成するために小さな変更のみが必要な場合がありますが、変更の性質について間違った印象を与える傾向があります。

編集：私はファウラーのリファクタリングリストをチェックしました、そしてこの〜100という名前のリファクタリングの中で、最後のものは"代替アルゴリズム"と呼ばれます。したがって、これを標準的な参照としてとると、記述されたフォームの最適化が特別な種類のリファクタリングと呼ばれる可能性のある小さな灰色の領域があります（ただし、IMHOは典型的なリファクタリングではありません）。また、すべてのリファクタリングに関するFowlerの目標は、既存のコードを書き換えずに保守性と進化性に重点を置いてデザインを改善することであり、明らかにパフォーマンスの最適化ではありません。

標準的な用語はないと思います。一般的に使用されるのは最適化ですが、改善、または高速化も正しいと思いますが、ハードウェアの変更ではなくコードの変更について話していることを明確にします。

他の人が言ったように、「最適化」はアルゴリズムのパフォーマンスを改善するための一般的な用語です。ただし、最適化とは、多くの場合、一定の要因を改善することです。漸近的（時間）の複雑さを軽減したことを簡潔かつ明確に述べたい場合、「漸近的パフォーマンスを改善した」と言います。人々はこれを「スケーリングの改善」と表現することがありますが、最近では特にあいまいです。

警告：漸近的な時間の複雑さを減らすことは、実際のコンテキストで最適化することと必ずしも同じではありません。多くの場合、漸近的に非最適なアルゴリズムが使用されます。これは、入力の範囲で、プログラムが実際には最適でないアルゴリズムにさらされるため、パフォーマンスが向上するためです。

コンテキストに依存します。

「二次実行時のパフォーマンスバグの修正」は、通常私が見ているものです。ただし、それが修正（コードの変更）に値するかどうかはコンテキストに依存します。

データベースには、時間の複雑さを改善するための多くのツールが用意されていることに注意してください。たとえば、データベースから上位N個の結果を取得するには、そう言うだけです。非効率なクラッジを組み込みの最適化された呼び出しに変換する場合、説明は不要に思えます。

コードレビュー（議論）に値する2次ランタイムを備えたアルゴリズムを検討する理由は、遅いため（遅いのは相対的であり、指数関数と比較すると2次は速いため）ではなく、人間の直感（顧客など）仲間のプログラマー）は、日常生活からの期待が混ざり合っているため、線形ランタイムとはかけ離れたソフトウェア機能に本質的に不快です。

ソフトウェアのパフォーマンスに関する顧客からの苦情の多くは、次の2つのカテゴリに分類されます。

• システム全体（ソフトウェアとハ​​ードウェア）は、推定使用量に基づいて指定されました。先週、すべてが正常に動作し、特定の機能は5秒未満で完了しました。今週、更新プログラムのインストール後、同じ機能に1分以上かかります。

  • これは、以前にベンチマークされたパフォーマンスとの比較です。顧客は、将来のパフォーマンスを人間の時間スケールの絶対的な尺度（数秒から数分）に保持します。

• システムに100個のジョブを送信しました。単一のジョブにかかる時間と比較して、処理に400倍の時間がかかるのはなぜですか？

  • 顧客は、処理時間が直線的であることを期待しています。実際、顧客は線形よりも遅いタスクが存在することを理解または受け入れることができません。

このため、顧客は両方が当てはまる場合、実行時間をバグと見なします。

• 線形より遅い
• 顕著な（典型的なタスクサイズを考慮して、人間の時間範囲内（秒または分より長い）に収まる）

二次ランタイムアルゴリズムが問題を引き起こさない（つまり、コード変更に値しない）ことを説明する正当な引数：

• この2次ランタイム関数によって通常処理されるタスクのサイズは、ある程度制限されています
• 典型的なサイズの範囲を考えると、実際の（絶対的な）実行時間はまだ無視できるほど小さい
• ユーザーが目立つほど大きいタスクを実際に送信しようとすると、ユーザーは実行時間が長いことを警告するメッセージを受け取ります。
• システムのユーザーはすべて専門家であるため、彼らは何をしているかを知っています。たとえば、APIのユーザーは、APIドキュメントの細字部分を読む必要があります。

典型的なアプリケーション開発に役立つ多くのアルゴリズムは、実際には線形よりも遅い（ほとんどの場合、ソートのようにO（N log N））ため、大規模なソフトウェアは実際に回避策を試みます。データ、または同様の効果を達成するヒストグラム（統計）フィルタリング手法を使用します。

これはソフトウェアの顧客に適用されますが、ソフトウェアライブラリまたはAPI関数のユーザーも「顧客」であると考える場合、答えは依然として適用されます。

元のアルゴリズムが正しく実装されていた場合（または無関係なバグ）、「アルゴリズムの変更」または「アルゴリズムの置換」の場合、そのような変更は正確にそれを行うことを意味するため、以前に使用されたアルゴリズムとは異なる時間の複雑度でアルゴリズムを置き換える。

前回の複雑さは、実装のバグによるものであった場合（例えば、何がO（n）はO（n個になったされている必要がありますように、あなたが誤ってシーケンスの内部ループの開始点をリセットしたと言う²当時））「固定二次コストのバグ」または同様の。

オーバーラップがあります。そのような場合、最初から作業をO（n）時間で実行でき、O（n ²）時間はエラーであることがわかっていれば、コードへの影響は同じです。最初に意図的にO（n ²）時間で実装し、その後、開始点をリセットしなくても正常に機能することを認識したため、O（n ²）アルゴリズムをO（n）アルゴリズムに置き換えました。

桁単位で最適化を高速化します。これは数学的に間違った言語ですが、順序が変更されるという考えを最もよく伝えています。

スケーラビリティを改善しました。また聞いた。