コード最適化の裏側

ソフトウェアを最適化することは良いことですが、不適切に使用すると、良いものが悪くなる可能性があります。コードを最適化するときに間違った道をたどると、その最適化によって開発コストが増加し、生産性が低下します。ソフトウェア開発時にはコストを考慮する必要があります。一般に、最適化されたソフトウェアは、より高品質にするために労力を費やす必要があるため、配信に時間がかかります。場合によっては、速度を最適化していないことがあります。組み込みシステムの場合はメモリ使用量の削減が考えられ、ハンドヘルド デバイスの場合はハードウェア リソースの制約が考えられます。最適化されたコードは、コードの可読性をある程度犠牲にする必要があるため、デバッグや保守が困難になることがよくあります。適切に最適化されたソフトウェアは害よりも多くの利益をもたらしますが、間違った最適化を行うと、まったく逆の結果が生じます。

コードを最適化するにはどうすればよいでしょうか? Rick Cook がいくつかの有益なアドバイスをくれます。

何のために最適化していますか?

最適化プロセスを開始するときに、なぜ最適化を行うのかを理解していないと、基本的に間違った道を進むことになります。達成しようとしている目標と、それに関連する最適化オプションを明確に理解する必要があります。これらの目標は明確かつ簡潔であり、プロジェクト マネージャーが理解できるほど単純である必要があり、最適化プロセス全体を通じてそれらを遵守する必要があります。ソフトウェア開発中には変更が頻繁に発生します。最初はこの目標に向けて最適化したいと考えていましたが、その後、他の目標に向けて最適化する必要があることが判明するかもしれません。これは事実ですが、これらの目標への変更を明確に文書化してください。

パフォーマンス テスト チームによって報告されるパフォーマンスの欠陥は、開発者以外の客観的なパフォーマンスの問題に起因するものである可能性がありますが、他方では、これらの欠陥レポートは明確に指摘します。問題が存在し、実行中に問題が発生しているか、ディスクのページングが頻繁かなど。開発者はこれらの欠陥から最適化を開始しますが、これは彼ら自身の想像上のパフォーマンス目標よりもはるかに合理的かつ客観的です。

最適化メトリクスには注意してください

適切なメトリクスを選択することは、最適化における重要なステップです。最適化の進行状況を測定するには、これらの基準を使用する必要があります。指標が間違っていれば、努力は無駄になってしまいます。適切な標準であっても、正しく適用する必要があります。場合によっては、アプリケーションのコードの実行に最も時間がかかる部分に焦点を当てることが正しいアプローチとなります。ただし、Unix/Linux カーネルはアイドル ループに最も多くの時間を費やすことに注意してください。ここでの問題は、注意しないと、問題の解決に役立たない指標を選択してしまう可能性があることです。

指標の選択は、どの指標が実際にユーザー エクスペリエンスを向上させるかによって決まります。たとえば、データベースに関連するパフォーマンス分析指標は数多くあります。開発者やパフォーマンス テスターは、バッファプールのサイズやデータベース接続プールのサイズなど、どの指標がアプリケーションの速度に実際に影響を与えるかを判断する必要があります。これは徐々に理解するプロセスです。

重要な部分のみを最適化します

これが効果的な最適化の鍵です。目標 (パフォーマンス、リソース) を達成するコードの部分を見つけて、そこに焦点を当てます。古典的な例としては、実際のパフォーマンスを低下させる要因がネットワーク接続の遅さである場合に、データベースの最適化に費やす時間が挙げられます。

目に映る外見に惹かれないでください。これらの症状が必ずしも問題を解決するとは限りません。発見が簡単で最適化が簡単だからといって、それが注目に値するというわけではありません。

高レベルの最適化の方が優れています

一般に、最適化のレベルが高くなるほど、最適化の効果がより顕著になります。この基準によれば、最良の最適化方法は、より優れたアルゴリズムを見つけることです。たとえば、一部の IT 部門では、従業員が特定のソフトウェアの最適化に数か月を費やしましたが、進歩が見られず、その後、これらの最適化を行うために新しい従業員のグループを雇用すると、すぐにパフォーマンスの問題がコードのどこかにあることがわかります。が使用されたり、特定のデータベース テーブルに数万件のレコードが追加されたりする場合などです。

時間をかけて基本的なアプリケーション アーキテクチャを確認し、最適化できる手がかりを探すことをお勧めします。ただし、高レベルの最適化は特効薬ではありません。コードをループ本体の可能な限り外側に移動するなど、いくつかの基本的なテクニック。

さらに、高度な最適化により、コード詳細の複雑なリファクタリングを回避できます。多くの場合、開発者は低レベルの最適化に最も興味を持っているため、欲求をコントロールして高いレベルから始めてください。

時期尚早に最適化しないでください

開発者はコーディング中に最適化の準備をしたいという衝動にかられます。一般的に言って、これは良い考えではありません。開発者は、そのような最適化の取り組みに価値があるかどうか確信が持てない場合があります。たとえば、乗算演算の代わりにシフト演算を実行する場合がありますが、このパフォーマンスの最適化により、非常に理解しにくいコードが生成されます。

開発作業と最適化作業を分離し、最初に正しいコードを開発してからそれを最適化することが最善です。時期尚早の最適化の問題は、開発者がソフトウェアのアーキテクチャ設計とコード構造について意図的に先入観を持ち、そのかなりの部分を心配する必要がないことです。これらの冗長な部分を最適化する必要がある場合があります。

直感ではなくパフォーマンス分析データに頼る

ソフトウェア システムのどこを最適化する必要があるかはわかっているつもりですが、直感は二の次であり、データが最優先です。そうしないと、非常に高速になるようにコードを最適化しても、実際にはほとんど呼び出されないことがわかります。

最適化の効果的な戦略は、最適化効果に対する作業の影響に応じて作業を分類することです。作業を開始する前に、最も大きな影響を与える「障害」を見つけてから、より小さな「障害」に対処します。

最適化によってすべての問題が解決されることは期待できません

最適化の重要なルールの 1 つは、最適化によってすべての問題を解決できるわけではないということです。たとえば、実行速度を上げると、より多くのシステム リソースが消費されます。主な最適化目標に対してトレードオフを行う必要があります。