プログラムの最適化

コンピュータサイエンスにおいて、プログラム最適化、コード最適化、またはソフトウェア最適化とは、ソフトウェアシステムの一部をより効率的に動作させたり、より少ないリソースで動作させたりするためにソフトウェアシステムを変更するプロセスです。^[1]一般に、コンピュータプログラムは、より高速に実行できるように、またはより少ないメモリストレージやその他のリソースで動作できるように、またはより少ない電力消費になるように最適化される場合があります。

「最適化」という語は「最適」という語と同じ語源を持っていますが、最適化のプロセスによって真に最適なシステムが生まれることはまれです。通常、システムは絶対的な意味で最適化されるのではなく、特定の品質メトリックに関してのみ最適化されます。この品質メトリックは、他の可能なメトリックとは対照的である可能性があります。その結果、最適化されたシステムは、通常、1 つのアプリケーションまたは 1 つのユーザーに対してのみ最適になります。プログラムが何らかのタスクを実行するのにかかる時間を短縮すると、メモリの消費量が増えるという代償を払う場合があります。メモリ スペースが貴重なアプリケーションでは、メモリの使用量を減らすために、意図的に低速のアルゴリズムを選択する場合があります。多くの場合、すべてのケースで適切に機能する「万能」の設計は存在しないため、エンジニアはトレードオフを行い、最も関心のある属性を最適化します。さらに、ソフトウェアを完全に最適化するために必要な労力 (これ以上の改善は不可能) は、ほとんどの場合、得られるメリットに対して妥当な範囲を超えています。そのため、最適化のプロセスは、完全に最適なソリューションに到達する前に停止されることがあります。幸いなことに、最も大きな改善はプロセスの早い段階で実現することがよくあります。

特定の品質メトリック (実行速度など) の場合でも、ほとんどの最適化方法は結果を改善するだけで、最適な出力を生成するという意図はありません。スーパー最適化は、真に最適な出力を見つけるプロセスです。

最適化はさまざまなレベルで行うことができます。通常、レベルが高いほど影響が大きく、プロジェクトの後半で変更するのが難しく、変更が必要な場合は大幅な変更または完全な書き直しが必要になります。したがって、最適化は通常、上位から下位への改良によって進められ、初期のゲインは大きく、少ない作業で達成され、後半のゲインは小さく、より多くの作業が必要になります。ただし、全体的なパフォーマンスはプログラムの非常に低レベルの部分のパフォーマンスに依存する場合があり、後半の段階での小さな変更や低レベルの詳細の早い段階での考慮が、非常に大きな影響を与えることがあります。通常、プロジェクト全体を通じて効率が考慮されていますが (これは大きく異なります)、大規模な最適化は、遅く行うべき改良であると見なされることがよくあります。長期にわたるプロジェクトでは、通常、最適化のサイクルがあり、1 つの領域を改善すると別の領域の制限が明らかになります。パフォーマンスが許容範囲内になるか、ゲインが小さすぎるかコストがかかりすぎる場合は、通常、これらのサイクルは削減されます。

パフォーマンスはプログラムの仕様の一部であるため、使用できないほど遅いプログラムは目的に適していません。60 Hz (フレーム/秒) のビデオ ゲームは許容されますが、6 フレーム/秒では許容できないほど途切れ途切れです。システムが十分なパフォーマンスを提供できるようにするために、パフォーマンスは最初から考慮されます。また、最終的なシステムが (最適化により) 許容できるパフォーマンスを達成するという確信を得るために、初期のプロトタイプはほぼ許容できるパフォーマンスを備えている必要があります。最適化はいつでも後で実行できるという信念から、この点が省略されることがあり、その結果、プロトタイプ システムは非常に遅く (多くの場合、1 桁以上)、アーキテクチャ的にパフォーマンス目標を達成できないために最終的に失敗するシステム ( Intel 432 (1981) など) や、許容できるパフォーマンスを達成するのに何年もかかるシステム (Java (1995) など) が生まれます。Java は、HotSpot (1999) でのみ許容できるパフォーマンスを達成しました。プロトタイプと本番システムの間でパフォーマンスがどの程度変化するか、また最適化にどの程度適応できるかは、不確実性とリスクの大きな原因となる可能性があります。

最高レベルでは、設計は、与えられた目標、制約、および予想される使用/負荷に基づいて、利用可能なリソースを最大限に活用するように最適化される場合があります。システムのアーキテクチャ設計は、そのパフォーマンスに大きく影響します。たとえば、ネットワーク遅延が制限されるシステム (ネットワーク遅延が全体的なパフォーマンスの主な制約となるシステム) は、ネットワーク トリップを最小限に抑えるように最適化され、理想的には、複数回のラウンドトリップではなく、単一の要求 (またはプッシュ プロトコルのように要求なし) が行われます。設計の選択は目標によって異なります。コンパイラを設計する場合、高速コンパイルが主な優先事項である場合、ワン パス コンパイラはマルチ パス コンパイラよりも高速です(同じ作業を想定)。ただし、出力コードの速度が目標である場合、より低速のマルチ パス コンパイラの方が、それ自体は時間がかかりますが、目標をより適切に満たします。プラットフォームとプログラミング言語の選択はこのレベルで行われ、それらを変更するには多くの場合完全な書き直しが必要ですが、モジュラー システムでは一部のコンポーネントのみの書き直しが許される場合もあります。たとえば、Python プログラムはパフォーマンスが重要なセクションを C で書き直すことができます。分散システムでは、アーキテクチャ (クライアント サーバー、ピアツーピアなど) の選択は設計レベルで行われ、すべてのコンポーネントを同期して置き換えることができない場合 (古いクライアントなど) は特に変更が困難な場合があります。

全体的な設計が決まったら、次は効率的なアルゴリズムとデータ構造の適切な選択、そしてこれらのアルゴリズムとデータ構造の効率的な実装です。設計の後は、アルゴリズムとデータ構造の選択がプログラムの他のどの側面よりも効率に影響します。一般に、データ構造はアルゴリズムよりも変更が困難です。これは、データ構造の仮定とそのパフォーマンスの仮定がプログラム全体で使用されるためです。ただし、関数定義で抽象データ型を使用し、具体的なデータ構造定義をいくつかの場所に制限することで、これを最小限に抑えることができます。

アルゴリズムの場合、これは主に、アルゴリズムが入力において定数 O(1)、対数 O(log n )、線形 O( n )、または場合によっては対数線形 O( n log n ) であることを保証することから成ります (空間と時間の両方において)。2 次複雑度 O( n ² ) のアルゴリズムはスケーリングできず、線形アルゴリズムであっても繰り返し呼び出されると問題が発生するため、通常は可能であれば定数または対数に置き換えられます。

漸近的な成長順序を超えて、定数要因が重要になります。漸近的に遅いアルゴリズムは、漸近的に速いアルゴリズムよりも高速または小型 (単純であるため) になる場合があります。これは、どちらも小さな入力に直面している場合であり、現実に発生する可能性があります。多くの場合、このトレードオフはサイズによって変化するため、 ハイブリッド アルゴリズムが最高のパフォーマンスを提供します。

パフォーマンスを向上させる一般的な手法は、作業を回避することです。良い例としては、一般的なケースで高速パスを使用することで、不要な作業を回避することでパフォーマンスが向上します。たとえば、ラテン文字には単純なテキスト レイアウト アルゴリズムを使用し、デーバナーガリー文字などの複雑なスクリプトに対してのみ複雑なレイアウト アルゴリズムに切り替えます。もう 1 つの重要な手法はキャッシュ、特に冗長な計算を回避するメモ化です。キャッシュの重要性から、システムには多くのレベルのキャッシュが存在することが多く、メモリ使用の問題や古いキャッシュによる正確性の問題が発生する可能性があります。

一般的なアルゴリズムと抽象マシンでのその実装を超えて、具体的なソース コード レベルの選択が大きな違いを生む可能性があります。たとえば、初期の C コンパイラでは、は無条件ループwhile(1)よりも遅くなりました。これは、が 1 を評価してから、それが真かどうかをテストする条件付きジャンプがあるのに対し、 には無条件ジャンプがあったためです。今日では、一部の最適化 (このようなもの)は、コンパイラを最適化することによって実行できます。これは、ソース言語、ターゲット マシン言語、およびコンパイラに依存し、理解または予測が難しく、時間の経過とともに変化する可能性があります。これは、コンパイラとマシン コードを理解することでパフォーマンスを改善できる重要な部分です。ループ不変コード移動と戻り値の最適化は、補助変数の必要性を減らし、回りくどい最適化を回避することでパフォーマンスを向上させることができる最適化の例です。 for(;;)while(1)for (;;)

ソースレベルとコンパイルレベルの間では、ディレクティブとビルドフラグを使用して、それぞれソースコードとコンパイラのパフォーマンスオプションを調整できます。たとえば、プリプロセッサ定義を使用して不要なソフトウェア機能を無効にしたり、特定のプロセッサモデルやハードウェア機能に合わせて最適化したり、分岐を予測したりすることができます。BSDのPortsやGentooのPortageなどのソースベースのソフトウェア配布システムは、この形式の最適化を利用できます。

最適化コンパイラを使用すると、実行可能プログラムが少なくともコンパイラが予測できる程度に最適化される ようになります。

最も低いレベルでは、特定のハードウェア プラットフォーム用に設計されたアセンブリ言語を使用してコードを記述すると、プログラマがマシン命令の全レパートリーを活用すれば、最も効率的でコンパクトなコードを作成できます。組み込みシステムで使用される多くのオペレーティング システムは、このため、従来はアセンブラ コードで記述されてきました。プログラム (非常に小さなプログラムを除く) は、時間とコストがかかることから、最初から最後までアセンブリで記述されることはほとんどありません。ほとんどのプログラムは、高級言語からアセンブリにコンパイルされ、そこから手動で最適化されます。効率とサイズがそれほど重要でない場合は、大部分が高級言語で記述されることがあります。

最新の最適化コンパイラと最近のCPUの複雑さが増すにつれ、コンパイラが生成するコードよりも効率的なコードを書くことが難しくなり、この「究極の」最適化手順を必要とするプロジェクトはほとんどありません。

今日書かれたコードの多くは、できるだけ多くのマシンで実行できるように作られています。その結果、プログラマーやコンパイラーは、新しい CPU が提供するより効率的な命令や古いモデルの癖を必ずしも活用しているわけではありません。さらに、特定のプロセッサ向けにそのような命令を使用せずに調整されたアセンブリ コードは、別のプロセッサでは最適とは言えず、コードの調整も異なる可能性があります。

現在では、一般的に、プログラマーはアセンブリ言語で記述するのではなく、逆アセンブラーを使用してコンパイラーの出力を分析し、高レベルのソース コードを変更して、より効率的にコンパイルできるようにしたり、非効率な理由を理解したりします。

ジャストインタイムコンパイラは、コンパイルのオーバーヘッドを犠牲にして、実行時データに基づいてカスタマイズされたマシン コードを生成できます。この手法は、最も初期の正規表現エンジンにまで遡り、Java HotSpot や V8 for JavaScript で広く普及しました。場合によっては、適応型最適化により、実際の入力やその他の要因に応じてパラメータを動的に調整することで、静的コンパイラの能力を超える実行時最適化を実行できることがあります。

プロファイル ガイドによる最適化は、実行時プロファイルに基づく事前 (AOT) コンパイル最適化手法であり、適応型最適化の動的手法の静的な「平均ケース」類似物に似ています。

自己修正コードは、コードを最適化するため、実行時の状況に応じて自分自身を変更できます。これは、アセンブリ言語プログラムではより一般的でした。

一部のCPU 設計では、実行時に最適化を実行できます。例としては、アウトオブオーダー実行、投機的実行、命令パイプライン、分岐予測などがあります。コンパイラは、命令スケジューリングなどを通じて、プログラムがこれらの CPU 機能を活用できるように支援できます。

コードの最適化は、プラットフォーム依存の手法とプラットフォーム非依存の手法に大まかに分類することもできます。後者はほとんどまたはすべてのプラットフォームで有効ですが、プラットフォーム依存の手法では、1 つのプラットフォームの特定のプロパティを使用したり、単一のプラットフォームまたは単一のプロセッサに依存するパラメータに依存したりします。したがって、異なるプロセッサ用に同じコードの異なるバージョンを作成または生成する必要がある場合があります。たとえば、コンパイル レベルの最適化の場合、プラットフォーム非依存の手法は一般的な手法 (ループの展開、関数呼び出しの削減、メモリ効率の高いルーチン、条件の削減など) であり、ほとんどの CPU アーキテクチャに同様に影響します。プラットフォーム非依存の最適化の優れた例は、内部 for ループで示されています。内部 for ループのあるループは、内部 for ループのないループや内部 while ループのあるループよりも単位時間あたりの計算量が多いことが観察されています。^{[2]一般に、これらは、プログラムを完了するために必要な}命令パスの合計長を短縮したり、プロセス中の合計メモリ使用量を削減したりするのに役立ちます。一方、プラットフォームに依存する技術には、命令スケジューリング、命令レベルの並列性、データレベルの並列性、キャッシュ最適化技術（つまり、さまざまなプラットフォーム間で異なるパラメータ）が含まれ、同じアーキテクチャの異なるプロセッサ上でも最適な命令スケジューリングが異なる可能性があります。

計算タスクは、効率の異なるいくつかの方法で実行できます。同等の機能を持つより効率的なバージョンは、強度削減と呼ばれます。たとえば、 1 からNまでのすべての整数の合計を取得することを目的とした次のCコード スニペットを考えてみましょう。

int i 、sum = 0 ; for ( i = 1 ; i <= N ; ++ i ) { sum += i ; } printf ( "合計: %d \n " 、sum );    
        
    

 

このコードは (算術オーバーフローがないと仮定して) 次のような数式を使用して書き直すことができます。

int sum = N * ( 1 + N ) / 2 ; printf ( "合計: %d \n " , sum );         
 

最適化は、最適化コンパイラによって自動的に実行されることもあり、同じ機能を維持しながら、より計算効率の高い方法 (アルゴリズム) を選択することです。これらの手法のいくつかについては、 「アルゴリズムの効率」を参照してください。ただし、多くの場合、無関係な機能を削除することで、パフォーマンスを大幅に向上させることができます。

最適化は、必ずしも明白または直感的なプロセスではありません。上記の例では、Nが十分に小さく、特定のハードウェアが乗算や除算よりも加算やループ演算の実行がはるかに高速である場合、「最適化された」バージョンは実際には元のバージョンよりも遅くなる可能性があります。

ただし、場合によっては、最適化はより複雑なアルゴリズムを使用し、「特別なケース」や特別な「トリック」を利用して複雑なトレードオフを実行することに依存します。 「完全に最適化された」プログラムは理解するのが難しく、最適化されていないバージョンよりも多くの障害が含まれる可能性があります。 明らかなアンチパターンを排除するだけでなく、コード レベルの最適化によって保守性が低下することもあります。

最適化は、一般的に、実行時間、メモリ使用量、ディスク容量、帯域幅、電力消費量、またはその他のリソースなど、パフォーマンスの 1 つまたは 2 つの側面のみを改善することに重点を置きます。これには通常、トレードオフ、つまり 1 つの要素を最適化すると他の要素が犠牲になります。たとえば、キャッシュのサイズを増やすと実行時のパフォーマンスは向上しますが、メモリ消費量も増加します。その他の一般的なトレードオフには、コードの明瞭性と簡潔性があります。

最適化を実行するプログラマーが、一部の操作についてはソフトウェアの性能を向上させるが、他の操作の効率を低下させるという代償を払う必要がある場合もあります。これらのトレードオフは、時には非技術的な性質のものである場合があります。たとえば、競合他社がベンチマーク結果を公開し、商業的な成功を高めるためにはその結果を上回らなければならないが、ソフトウェアの通常の使用の効率が低下するという負担が伴う場合などです。このような変更は、冗談めかして悲観化と呼ばれることがあります。

最適化には、システム内のボトルネック(パフォーマンスを制限する要因となるコンポーネント)を見つけることが含まれる場合があります。コードに関して言えば、これは多くの場合、ホット スポット (必要なリソースを主に消費するコードの重要な部分) になりますが、I/O レイテンシやネットワーク帯域幅などの別の要因である場合もあります。

コンピュータサイエンスでは、リソースの消費はしばしばべき乗分布の形に従い、リソースの80％が通常20％の操作によって使用されていることを観察することで、パレートの法則をリソースの最適化に適用できます。 ^[3]ソフトウェアエンジニアリングでは、コンピュータプログラムの実行時間の90％がコードの10％の実行に費やされていると近似することがよくあります（この文脈では90/10の法則として知られています）。

より複雑なアルゴリズムとデータ構造は多くの項目で優れたパフォーマンスを発揮しますが、シンプルなアルゴリズムは少量のデータに適しています。複雑なアルゴリズムのセットアップ、初期化時間、定数要素は利点を上回る可能性があるため、ハイブリッドアルゴリズムまたは適応型アルゴリズムは単一のアルゴリズムよりも高速になる可能性があります。パフォーマンスプロファイラーを使用すると、どの機能がどの条件に適合するかを絞り込むことができます。^[4]

場合によっては、メモリを追加するとプログラムの実行速度が速くなることがあります。たとえば、フィルタリング プログラムは通常、各行を読み取り、その行をフィルタリングしてすぐに出力します。この場合、1 行分のメモリしか使用されませんが、ディスク読み取りの遅延により、パフォーマンスは低下するのが一般的です。結果をキャッシュすることも同様に効果的ですが、メモリ使用量も大きくなります。

最適化により可読性が低下し、パフォーマンスを向上させるためだけに使用されるコードが追加される可能性があります。これによりプログラムやシステムが複雑になり、保守やデバッグが困難になる可能性があります。その結果、最適化やパフォーマンス チューニングは開発段階の最後に実行されることがよくあります。

ドナルド・クヌースは最適化に関して次の 2 つの発言をしました。

「私たちは、97%程度の小さな効率性については忘れるべきです。早まった最適化は諸悪の根源です。しかし、その重要な3%の機会を逃すべきではありません。」^[5]

（彼は数年後にこの引用をトニー・ホーアの言葉だと主張したが^[6]、ホーアはこのフレーズを作ったことを否定しているため、これは間違いだったかもしれない。^[7]）

「確立されたエンジニアリング分野では、簡単に得られる12％の改善は決して限界とはみなされず、ソフトウェアエンジニアリングでも同じ視点が優先されるべきだと私は信じています。」^[5]

「時期尚早な最適化」とは、プログラマーがパフォーマンスを考慮してコードの設計を行う状況を表すときに使われるフレーズです。最適化によってコードが複雑になり、プログラマーが最適化に気を取られるため、設計が本来あるべきほどきれいでなくなったり、コードが不正確になったりする可能性があります。

プログラムの特定の部分を最適化するかどうかを決定するときは、常にアムダールの法則を考慮する必要があります。つまり、プログラム全体への影響は、その特定の部分に実際に費やされる時間の量に大きく依存しますが、これはパフォーマンス分析を行わずにコードを見ただけでは必ずしも明らかではありません。

したがって、最初に設計し、その設計に基づいてコードを記述し、次に結果のコードをプロファイル/ベンチマークして、どの部分を最適化すべきかを確認する方がよいアプローチです。シンプルで洗練された設計は、この段階で最適化する方が簡単な場合が多く、プロファイリングによって、時期尚早な最適化では対処できなかった予期しないパフォーマンスの問題が明らかになることがあります。

実際には、ソフトウェアを最初に設計するときにパフォーマンス目標を念頭に置く必要があることがよくありますが、プログラマーは設計と最適化の目標のバランスをとります。

現代のコンパイラとオペレーティング システムは非常に効率的であるため、意図したパフォーマンスの向上が実現されないことがよくあります。たとえば、アプリケーション レベルでデータをキャッシュし、それをオペレーティング システム レベルで再度キャッシュしても、実行の改善は得られません。それでも、プログラマーが製品コードから失敗した最適化を削除することはまれです。また、ハードウェアの進歩により、潜在的な改善がほとんどなくなることも事実ですが、目的が無効になった後も、目立たないコードは将来にわたって存続します。

マクロを使用したコード開発中の最適化は、言語によって異なる形をとります。

CやC++などの一部の手続き型言語では、マクロはトークン置換を使用して実装されます。現在では、多くの場合、インライン関数を型安全な代替手段として使用できます。どちらの場合も、インライン関数本体は、定数の折りたたみなど、コンパイラによるコンパイル時のさらなる最適化を受けることができ、一部の計算がコンパイル時に移動することがあります。

多くの関数型プログラミング言語では、マクロは解析時に構文木/抽象構文木の置換を使用して実装されており、これによりマクロの使用がより安全になると主張されています。多くの場合、解釈が使用されるため、これはそのような計算が解析時にのみ実行されることを保証する 1 つの方法であり、場合によっては唯一の方法です。

このスタイルのマクロはLispから生まれたもので、 ^{[引用が必要] 、このようなマクロはしばしば「Lisp 風マクロ」と呼ばれます。同様の効果は、} C++のテンプレート メタプログラミングを使用することで実現できます。

どちらの場合も、作業はコンパイル時に移されます。一方のCマクロと、もう一方のLisp のようなマクロおよびC++ テンプレート メタプログラミングとの違いは、後者のツールではコンパイル時/解析時に任意の計算を実行できるのに対し、 Cマクロの展開では計算は実行されず、計算を実行するには最適化機能に依存するという点です。さらに、Cマクロは再帰や反復を直接サポートしていないため、チューリング完全ではありません。

ただし、他の最適化と同様に、プロジェクトが完了する前に、このようなツールが最も大きな影響を与える場所を予測することは難しいことがよくあります。

カテゴリ:コンパイラの最適化も参照してください

最適化はコンパイラによって自動化することも、プログラマによって実行することもできます。通常、ローカル最適化ではメリットが限られており、グローバル最適化ではメリットが大きくなります。通常、最も強力な最適化は、より優れたアルゴリズムを見つけることです。

システム全体の最適化は、自動最適化には複雑すぎるため、通常はプログラマーが行います。このような状況では、プログラマーまたはシステム管理者が明示的にコードを変更して、システム全体のパフォーマンスを向上させます。これにより効率が向上しますが、自動最適化よりもはるかにコストがかかります。多くのパラメータがプログラムのパフォーマンスに影響を与えるため、プログラム最適化のスペースは広くなります。メタヒューリスティックと機械学習は、プログラム最適化の複雑さに対処するために使用されます。^[8]

プロファイラー(またはパフォーマンス アナライザー)を使用して、最も多くのリソースを消費しているプログラムの部分 (ボトルネック) を見つけます。プログラマーは、ボトルネックがどこにあるかを明確に把握していると思うことがありますが、その直感はしばしば間違っています。^[要出典]重要でないコード部分を最適化しても、全体的なパフォーマンスの向上にはほとんど役立ちません。

ボトルネックが特定されている場合、最適化は通常、プログラムで使用されるアルゴリズムの再検討から始まります。多くの場合、特定のアルゴリズムを特定の問題に合わせて調整することで、汎用アルゴリズムよりも優れたパフォーマンスを実現できます。たとえば、膨大な項目のリストをソートするタスクは、通常、最も効率的な汎用アルゴリズムの 1 つであるクイックソートルーチンを使用して実行されます。ただし、項目の特性が利用できる場合 (たとえば、項目がすでに特定の順序で配置されている場合)、別の方法、またはカスタムメイドのソート ルーチンを使用することもできます。

プログラマーが最適なアルゴリズムが選択されていることをある程度確信したら、コードの最適化を開始できます。ループを展開したり (ループのオーバーヘッドを減らすため。ただし、CPU キャッシュが過負荷になると速度が低下する可能性があります)、できるだけ小さいデータ型を使用したり、浮動小数点の代わりに整数演算を使用したりすることができます。(これらのテクニックやその他のテクニックについては、アルゴリズムの効率に関する記事を参照してください。)

パフォーマンスのボトルネックは、プログラムで使用されるアルゴリズムやデータ構造ではなく、言語の制限が原因である場合があります。場合によっては、プログラムの重要な部分を、基盤となるマシンへのより直接的なアクセスを提供する別のプログラミング言語で書き直すことができます。たとえば、Pythonなどの非常に高水準な言語では、速度を上げるためにCでモジュールが記述されるのが一般的です。すでに C で記述されたプログラムには、アセンブリで記述されたモジュールを含めることができます。Dで記述されたプログラムでは、インライン アセンブラを使用できます。

このような状況では、セクションの書き直しは「効果的」です。これは、90/10 の法則として知られる一般的な「経験則」によるものです。この法則では、コードの 10% に 90% の時間が費やされ、残りの 90% のコードには 10% の時間しか費やされないとされています。したがって、プログラムのごく一部を最適化することに知的努力を注ぐだけで、正しい部分を見つけることができれば、全体の速度に大きな効果をもたらすことができます。

手動での最適化には、読みやすさを損なう副作用がある場合があります。したがって、コードの最適化は慎重に文書化 (できればインライン コメントを使用) し、将来の開発への影響を評価する必要があります。

自動最適化を実行するプログラムは、オプティマイザと呼ばれます。ほとんどのオプティマイザはコンパイラに組み込まれており、コンパイル時に動作します。オプティマイザは、生成されたコードを特定のプロセッサに合わせて調整できる場合がよくあります。

現在、自動化された最適化は、ほぼ例外なくコンパイラ最適化に限定されています。ただし、コンパイラ最適化は通常、かなり一般的な最適化の固定セットに限定されているため、問題の説明と言語固有の最適化を受け入れ、エンジニアがカスタム最適化を指定できる最適化ツールに対する需要が高まっています。最適化の説明を受け入れるツールはプログラム変換システムと呼ばれ、C++ などの実際のソフトウェア システムに適用され始めています。

一部の高級言語 ( Eiffel、Esterel ) では、中間言語を使用してプログラムを最適化します。

グリッド コンピューティングまたは分散コンピューティングは、使用率の高いコンピューターからアイドル時間のコンピューターにタスクを移動することで、システム全体を最適化することを目的としています。

場合によっては、最適化にかかる時間自体が問題になることもあります。

既存のコードを最適化しても、通常は新しい機能は追加されません。さらに悪いことに、以前は機能していたコードに新しいバグが追加される可能性があります (変更の場合も同様です)。手動で最適化されたコードは、最適化されていないコードよりも「読みやすさ」が劣る場合があるため、最適化によってコードの保守性にも影響が出る可能性があります。最適化にはコストがかかるため、投資に見合う価値があることを確認することが重要です。

自動オプティマイザー (または最適化コンパイラ、コード最適化を実行するプログラム) 自体も、ターゲット プログラムの効率をさらに向上させるか、またはそれ自体の動作を高速化するために最適化する必要がある場合があります。最適化を「オン」にして実行すると、コンパイルに通常より時間がかかりますが、これは通常、プログラムが非常に大きい場合にのみ問題になります。

特に、ジャストインタイム コンパイラの場合、ターゲット コードと一緒に実行されるランタイムコンパイル コンポーネントのパフォーマンスが、全体的な実行速度を向上させる鍵となります。

Wikibooksには「スピードのためのコードの最適化」というテーマの本があります。

• Jon Bentley :効率的なプログラムの作成、ISBN 0-13-970251-2。 
• ドナルド・クヌース：コンピュータプログラミングの芸術
• 高速な数値コードの書き方: 簡単な入門
• Ulrich Drepper 著「すべてのプログラマがメモリについて知っておくべきこと」 – 現代のメモリ サブシステムの構造を説明し、それを効率的に活用する方法を提案します。
• 「Linux マルチコア パフォーマンス分析と最適化の概要」、Philip Mucci によるプレゼンテーション スライド
• プログラミングの最適化 (Paul Hsieh 著)
• 効率的なプログラムの作成 (「ベントレーのルール」) Jon Bentley著
• 「パフォーマンスアンチパターン」Bart Smaalders 著