最新のハードウェアにおける複雑さと保守性
現代のハードウェアとメモリが安価になっている今日、アルゴリズムやデータ構造の複雑さを分析するために努力を費やすのはどのくらい意味がありますか？
代わりに、複雑さの最適化よりも、クリーンで保守可能なコード、読み取り可能なコードに焦点を当てたほうがよいのではないでしょうか。
注：組み込みシステムや同様の種類の制約のあるシステムについては話していません。
まず、あなたの質問の前提に質問します。意図的に「複雑さの最適化」を実行する人は誰もいません。パフォーマンスやリソースの制約を克服するために最適化が実行され、それが仕事を成し遂げれば複雑さは許容されます。アルゴリズムとデータ構造の分析がうまく行われると、冗長な情報や不要な作業を認識できるようになり、よりシンプルで保守しやすいコードを記述できるようになります。これにより、パフォーマンスも向上します。
第二に、より強力なハードウェアを使用すると、昨日の問題をより明白で直接的な方法で解決できる可能性がありますが、私たちのほとんどは、より新しく、より難しい問題に移らなければなりません。あなたのワードプロセッサはついに十分に速くなりましたか？これで、Webブラウザ内のスクリプト言語で完全に機能するようになりました。毎月インターネット全体の詳細なインデックスを作成したいですか？結構です。グーグルは10年前にそれをすることができた。残念ながら、Googleについていくには、クロールするページの数を毎年1桁増やす必要があります。ヒトゲノムの最初のコピーをシーケンスするのに10年かかりましたが、今では1日でシーケンスできるようにしたいと考えています。
ハードウェアが強力になるにつれて、私たちが取り組みたい問題の難しさはさらに急速に高まっています。
はい、最初に正確性、次に読みやすさと保守性、そして（もしあれば）パフォーマンスに焦点を当てることを常にお勧めします。最近のほとんどの場合、パフォーマンスは重要な制約ではありません。
とはいえ、アルゴリズムとデータ構造を正しく選択することは依然としてベストプラクティスです。これが、適切な種類の標準ライブラリの並べ替え方法を呼び出すこと、または特定の使用パターンに対して適切な種類のコンテナを使用することを意味する場合、通常は後で簡単に変更できます。ただし、ある種の重要なアルゴリズムを実際に実装する必要がある場合は、事前にパフォーマンス要件について検討する価値があります。文字列検索アルゴリズムが数十文字のテキストで1日に10回呼び出される場合など、パフォーマンス要件はそれほど多くない可能性があります。その場合、アルゴリズムオプションの調査/設計とそのパフォーマンスの調整に多くの時間を費やす価値はないことは明らかです。ただし、1日に数千回呼び出され、毎回100万文字が呼び出される場合、不適切に選択/実装されたアルゴリズムによるパフォーマンスの欠如により、プログラムが実際に停止する可能性があります。
したがって、潜在的なパフォーマンスのホットスポットを十分に早期に調べて特定し、そのようなホットスポットがある場合は慎重に設計する必要があります。エンベロープの裏側の計算を実行して、分析および設計段階でのパフォーマンス、スループット、応答時間などを見積もります。これらは、システムに関する非現実的な期待/仮定を明らかにするのに役立つ場合があります。システムのエンドツーエンドのスケルトンをできるだけ早く構築してから、大まかな測定（ダミーデータ、単純なワークフローなど）を実行して、実際のパフォーマンスと期待されるパフォーマンスを把握できます。また、予想される短期/長期のトラフィックの増加も考慮する必要があります。 Webサイトは最初は50人のユーザーでうまく機能するかもしれませんが、そのユーザーベースが1年後に数千人に増えると深刻な問題に直面する可能性があります。システムがすでに完全に混雑しているときにパフォーマンスの問題を解決しようとすることは、非常に苦痛で危険です。多くの場合、システムが輻輳のポイントに近づいていることは明らかではありません。パフォーマンスは常に許容できるように見える場合があり、その後、突然劇的に低下します。やがてこれらの問題を予測して防ぐことができない場合は、怒っているユーザーの電話がサポートラインに殺到し、上司が首に息を吹き込んで即座の解決策を待っている間に、問題を解決する必要があります...
現代のハードウェアとメモリが安価になっている今日、アルゴリズムやデータ構造の複雑さを分析するために努力を費やすのはどのくらい意味がありますか？
それは今日でも理にかなっています。
おそらく私が与えることができる最も良い例は、CPUの数の増加（頻度よりも）の例です。これらの物理的な最大値がまだあるため、適切なアルゴリズムと構造を選択することは依然として重要です。適切に作成されたプログラムは、CPU時間またはリソースのほんの一部しかかかりません。
適切なアルゴリズム/実装を選択するための1つの明白な代替手段は、並列実行（PE）を使用することです。場合によっては問題ありませんが、PEが常に適切なソリューションであるとは限りません。
- 書くのは非常に複雑になる可能性があります。
- デバッグ、テスト、および保守が非常に難しい場合があります。
- 多くの問題are PEの良い候補ですが、多くはドメインにうまく拡張されていません。
pEを正しく実装するために必要な労力を考えると、適切なアルゴリズムと構造は依然として重要であり、多くの場合、はるかに単純で強力なソリューションです。
それで、あなたがその上限に達したとしましょう：あなたはそのプログラムをPE用に改造したいですか、それとも適切なタイプ/アルゴリズム/実装を使用したい（またはプログラムが使用していることを確認したい）ですか？
pEを選択した場合でも、プログラムは（ほとんどの場合）最終的にmore実行時のピーク/合計リソース==を消費します。
代わりに、複雑さの最適化よりも、クリーンで保守しやすいコード、読み取り可能なコードに焦点を当てたほうがよいのではないでしょうか。
2つは共存できます。 （一部の言語またはランタイムはこれに悪影響を与える可能性があり、重複が少なくなりますが、問題は言語に依存しません）
ユーザーの観点から重要なのは反応性です。ノートブックまたはタブレットの電源を入れたらすぐに準備することが非常に重要です。これは、巨大なCPU周波数と小さなメモリレイテンシでのみ達成されるわけではありません。
完全性とはアルゴリズムの複雑さも意味する場合、重要な点はスケーラビリティです。問題がO（exp N）の場合、ハードウェアパフォーマンスは限られた解決策です。
素晴らしい、これまでにない速さの競走馬のブリーダーが太りすぎの、これまでにない太った騎手を補うことができる日を想像することはできません。
ハードウェアエンジニアは、より細かいリソグラフィ、より高速なクロック、キャッシュのレベル、チップ上の複数のCPUを作成することをノックアウトします。一方、それらのチップを実行しなければならないソフトウェアを作成する人々は、「パフォーマンス-誰が気にしますか？」と言います。
パフォーマンスは重要です。遅さは他の種類のバグと同じです。
あなたはそれらを作らないようにすべきです。しかし、あなたはそれらを作るでしょう（あなたが働いているなら）そしてあなたはそれらを取り除く方法を知っているべきです。
要件を確認してください。許容可能なパフォーマンスを構成するものを具体的、測定可能、客観的な用語で体系化して、利害関係者、管理者、および開発者全体で統一されたビューを持つようにします。これを、アプリケーションアーキテクチャ、アプリケーションとハードウェアの設計、機能とパフォーマンスに関するQAのガイドとして、目標を達成したかどうか、最適化するために時間を費やす場所としない場合について説明します。
パフォーマンスを無視し、主要な利害関係者にとって重要な明確な要件としてあなたを噛むことになった場合、事後に取り組むよりもパフォーマンスの設計がはるかに簡単であるため、あなたはsr * wedになります。