関数のBig O実行時間を変更するとき、それを何と呼びますか
データベースをO(n^2)時間でソートする関数があるとします。 O(n log(n))時間で実行されるようにリファクタリングしたいと思います。そうすることで、戻り値と入力を同等に保ちながら、操作の基本的な方法を変更します。
このリファクタリングアクティビティとは何ですか？
実行時の大きなO速度を変更せずにアルゴリズムを高速化できるため、「高速化」は適切ではないようです。
「簡素化」も正しくないようです。
このアクティビティを何と呼びますか？
更新
私が見つけた最良の答えは漸近的な時間の複雑さを減らすことです
通常、「パフォーマンスの最適化」と呼ばれますが、この用語は通常、変更されないコードの変更を指すため、「リファクタリング」とは呼びません。その目に見える動作を変更します。そしてBig-Oの変更は間違いなく私が目に見える変更と呼ぶものです。
そうすることで、操作の基本的な方法を変更します
この場合、最適化はその関数のrewriteです。すべての最適化は、「Big-O」が変更されたとしても、必ずしも書き換えであるとは限りません。そのような改善を達成するには、わずかな変更のみが必要な場合がありますが、それでも「リファクタリング」という用語を使用することに消極的です。変化の性質について誤った印象を与える傾向があります。
編集：私は Fowler's refactoring list をチェックし、この〜100の名前付きリファクタリングの中で、最後の1つは "Substitute Algorithm" と呼ばれています。したがって、これを正規の参照とすると、記述されたフォームの最適化が特別な種類のリファクタリングと呼ばれる可能性がある小さな灰色の領域があります（ただし、IMHOは一般的なものではありません）。また、すべてのリファクタリングに関するFowlerの目標は、既存のコードを書き直さずに保守性と発展性に焦点を合わせて設計を改善することであり、明らかにパフォーマンスの最適化ではありませんでした。
標準的な用語はないと思いますが、一般的に使用されるのはoptimizingですが改善、または高速化も、ハードウェアではなくコードの変更について話していることを明確にすることも正しいでしょう変更。
他の人が言ったように、「最適化」はアルゴリズムのパフォーマンスを改善するための一般的な用語です。ただし、最適化は多くの場合、一定の要因を改善することを意味します。漸近的（時間）の複雑さを減らしたと簡潔かつ明確に述べたい場合は、「漸近的パフォーマンスを向上させた」と言います。時々人々はこれを「スケーリングの改善」と表現しますが、これは今日特にあいまいです。
警告：漸近的な時間の複雑さの軽減は、実用的なコンテキストでの最適化と必ずしも同じではありません。多くの場合、漸近的に最適でないアルゴリズムが使用されます。これは、入力の範囲でプログラムが実際には最適でないアルゴリズムにさらされるため、パフォーマンスが向上するためです。
コンテキストに依存します。
「2次ランタイムパフォーマンスバグの修正」は、通常私が目にするものです。ただし、それが修正に値するかどうか（コードの変更）はコンテキストに依存します。
データベースには、時間の複雑さを改善するための多くのツールが用意されていることに注意してください。たとえば、データベースから上位N件の結果を取得するには、そのように言います。非効率的なkludgeを組み込みの最適化された呼び出しに変換する場合、説明は不必要に思えます。
コードレビュー（ディスカッション）に値する二次ランタイムのアルゴリズムを検討する理由は、遅い（相対速度であり、二次関数は指数関数と比較すると速い）ためではなく、人間の直感（顧客など）のためです。仲間のプログラマー）は、日常生活からの期待が混ざり合っているため、線形ランタイムから大きく逸脱しているソフトウェア機能に本質的に不快です。
ソフトウェアのパフォーマンスに関する多くの顧客の不満は、次の2つのカテゴリに分類されます。
システム全体（ソフトウェアおよびハードウェア）は、推定使用量に基づいて指定されました。先週、すべてが正常に実行され、特定の機能にかかった時間は5秒未満でした。今週、アップデートをインストールした後、同じ機能が1分以上かかります。
- これは、以前にベンチマークされたパフォーマンスとの比較です。顧客は将来のパフォーマンスを人間の時間スケール（秒から分）の絶対的な基準に保持します。
システムに100個のジョブを送信しました。単一のジョブにかかる時間と比較して、処理に400倍の時間がかかるのはなぜですか？
- 顧客は処理時間が直線的であることを期待しています。実際、顧客は線形よりも遅いタスクが存在することを理解または受け入れることができません。
このため、両方に当てはまる場合、顧客は実行時間をバグと見なします。
- 線形よりも遅い
- 目立つ（つまり、典型的なタスクサイズを考えると、人間の時間範囲（秒または分よりも長い）内にある）
2次ランタイムアルゴリズムは問題を引き起こさない（つまり、コードの変更に値しない）ことを説明する正当な引数：
- この2次ランタイム関数で通常処理されるタスクのサイズは、ある程度制限されています
- 典型的なサイズ範囲が与えられた場合、実際の（絶対）実行時間は、却下されるのに十分なほど小さい
- 目立つほどの大きさのタスクをユーザーが実際に送信しようとすると、実行時間が長いことを警告するメッセージが表示されます。
- システムのユーザーはすべてエキスパートなので、彼らは自分が何をしているかを知っています。たとえば、APIのユーザーは、APIドキュメントの細かい説明を読む必要があります。
典型的なアプリケーション開発に役立つ多くのアルゴリズムは、実際には線形よりも遅い（ほとんどがソートのようにO（N log N））。したがって、大規模なソフトウェアは実際には、データ、または同様の効果を達成するヒストグラム（統計）フィルタリング手法を使用します。
これはソフトウェアの顧客に適用されますが、ソフトウェアライブラリまたはAPI関数のユーザーも「顧客」であると見なす場合、答えは依然として適用されます。
元のアルゴリズムが正しく実装されている場合（または無関係なバグがある場合）、"アルゴリズムの変更"または"アルゴリズムの置換"のような変更は、正確にそれを行っていることを意味します。以前に使用されていたアルゴリズムを、異なる時間の複雑さを持つアルゴリズムに置き換えます。
前回の複雑さが実装のバグによるものである場合（たとえば、シーケンスの内部ループの開始点を誤ってリセットして、本来あるべきO(n)がO（n2））それから"二次コストのバグを修正する"または同様です。
オーバーラップがあります。そのような場合、作業がO(n)時間とO（nで実行できることが最初からわかっている場合、コードへの影響は同じです。2）時間はエラーでした、または最初に意図的にO（n2）時間後に、開始点をリセットしなくても正しく機能することに気づき、O [nをO(n)アルゴリズムに置き換えました2） 1。
次数/次数による速度の最適化。これは数学的に正しくない言語ですが、次数の概念を最もよく伝えています変更されます。
スケーラビリティの向上。も聞こえました。