最適化は様々なレベルで行われる。最も高いレベルの最適化は設計段階に行われる。設計が最適化されていれば、実装でも効率的なアルゴリズムを利用でき、品質のよいコードになるという利点がある。コンパイラ最適化を使えば、実行ファイルがさらに最適化される。最も低いレベルでは、コンパイラを使わずに人間がアセンブリ言語で最適なコードを書く。コンパイラ最適化の技術の進歩と最近のCPUの複雑さのため、コンパイラよりも最適なコードを人間が書くには大変な技能を要する。そのため、このような最適化を行うプロジェクトは滅多にない。最適化は例外的なケースを考慮しつつ、複雑な妥協点を探ることが多い。従って最適化されたプログラムはプログラマが理解できないほど難解になることも多い。可能であれば等価であることが保証されながらプログラムを変形させるなどの手法でバグの可能性をゼロにすべきだが、できない場合、できていないコードではバグを多く含む危険性がある。基本.最適化(特に自動的に行われる最適化)は、機能的に等価でより効率的な方法を選択することに他ならない。しかし、効果の大きい性能改善は無駄な機能を省いて実際の問題に集中することで実現されることも多い。トレードオフ.最適化は一般に性能の様々な観点(実行時間、メモリ使用量、ディスク使用量、帯域幅、電力消費など)の一部だけを改善する。そこには何らかのトレードオフがあり、ある観点を犠牲にして別の観点を最適化することになる。例えば、キャッシュを大きくすれば実行時の性能は改善されるが、キャッシュも含めたメモリ消費は増大する。その他の典型的なトレードオフとしては、コードの読みやすさとコンパクトさ、デバッグのし易さ(命令の入替や冗長なコードの削除、関数インライン展開などの最適化の結果として、ソースコードとバイナリコードの間での対応関係が付け難くなったりブレークポイントを設定できる行数が減ったり、ブレークポイントでブレークしなかったり、とデバッグ時にコードの振る舞いや変数の変化が理解しにくくなる)などがある。