開発の開始時または終了時に、パフォーマンスを向上させるためにソフトウェアを最適化するのはいつですか？

私はジュニアソフトウェア開発者であり、パフォーマンス（速度）を向上させるためにソフトウェアを最適化するのに最適な時期はいつになるのか疑問に思っていました。

ソフトウェアが非常に大きく、管理が複雑ではないと仮定すると、最初にそれを最適化するためにより多くの時間を費やす方が良いでしょうか、またはすべての機能を正しく実行するソフトウェアを開発し、パフォーマンスを向上させるために最適化を進めるべきですか？

一番大切なことは、いつまでも読みやすくすることです。遅くても読みやすい場合は、修正できます。壊れていても読みやすい場合は、修正できます。判読できない場合は、他の誰かにこれが何をすべきかさえ尋ねなければなりません。

読みやすくすることに集中しているとき、コードのパフォーマンスがどれほど優れているかは驚くべきことです。あまりにもそうなので、私は一般的に気にする理由が与えられるまでパフォーマンスを無視しています。これは、速度を気にしないという意味ではありません。私がやります。読みづらくすると実際に解決が速くなる問題はほとんどないことがわかりました。

このモードから抜け出せるのは次の2つだけです。

1. 私が本格的にチャンスを参照すると、大きなOの改善、それでもときのみ、nは誰もが気になること十分に大きいです。
2. 実際のパフォーマンスの問題を示すテストがある場合。数十年の経験があっても、数学よりもテストを信頼しています。そして、私は数学が得意です。

いずれにせよ、最速ではない可能性があるため、ソリューションを試してはいけないと考えさせることで、分析の麻痺を避けます。変更を加えると、変更しやすいデザインを使用せざるを得なくなるため、複数のソリューションを試してみると、実際にコードにメリットがあります。柔軟なコードベースは、後で必要になったときに、より速く作成できます。速度よりも柔軟に選択すると、必要な速度を選択できます。

特定のレベルのパフォーマンスが必要な場合（非機能要件）、それは最初から設計目標にする必要があります。たとえば、これは、適切なテクノロジーや、プログラム内のデータフローの構造に影響を与える可能性があります。

しかし、一般的に、コードを記述する前に最適化することはできません。最初に動作させ、次に正しく動作させ、最後に高速化します。

ほとんどの機能を実装する前に最適化する際の大きな問題の1つは、間違った場所で次善の設計決定に縛られてしまうことです。保守性とパフォーマンスの間にはしばしば（ただし、必ずしもそうではない）トレードオフがあります。プログラムのほとんどの部分は、パフォーマンスにはまったく関係ありません！典型的なプログラムには、最適化する価値のあるホットスポットがいくつかあります。したがって、パフォーマンスを必要としないすべての場所でパフォーマンスの保守性を犠牲にすることは、本当に悪いトレードです。

保守性の最適化がより良いアプローチです。あなたが費やす場合は賢さを保守し、クリアなデザインで、あなたは、クリティカルセクションを識別するために、長期的にはそれが簡単に見つけて、安全に全体のデザインを損なうことなく、それらを最適化します。

パフォーマンス（速度）を向上させるためにソフトウェアを最適化する最適なタイミングはいつですか。

まず、パフォーマンスはスピードと同じであるという概念を頭から取り除いてください。 パフォーマンスとは、ユーザーがパフォーマンスと考えるものです。

アプリケーションがマウスクリックに対して2倍の速さで応答し、10マイクロ秒から5マイクロ秒に移行する場合、ユーザーは気にしません。アプリケーションがマウスクリックに対して2倍速く応答し、4000年から2000年になったとしても、ユーザーは気にしません。

アプリケーションを2倍高速にし、マシン上のすべてのメモリを使い果たしてクラッシュした場合、ユーザーはアプリケーションが2倍高速であることを気にしません。

パフォーマンスは、特定のユーザーエクスペリエンスを実現するために、リソース消費に関して効果的なトレードオフを行う科学です。ユーザーの時間は重要なリソースですが、「より速く」ということはありません。パフォーマンスの目標を達成するには、ほとんどの場合トレードオフが必要であり、多くの場合、スペースと時間のトレードオフ、またはその逆です。

ソフトウェアが管理するのに極端に大きく複雑ではないと仮定する

それはひどい仮定です。

ソフトウェアが大きくて管理が複雑でない場合、ユーザーが気にする興味深い問題はおそらく解決せず、おそらく最適化は非常に簡単です。

最初にそれを最適化するためにより多くの時間を費やす方が良いでしょうか、それとも単にすべての機能を正しく実行するソフトウェアを開発し、それからパフォーマンスを改善するために最適化に進むべきですか？

空白のページに座って、次のように書きvoid main() {}ます。最適化を開始しますか？最適化するものは何もありません！正しい順序は次のとおりです。

• コンパイルする
• 正しくする
• エレガントに
• 早くする

他の順序でそれを行おうとすると、混乱した誤ったコードになってしまい、間違った答えを本当に素早く生成し、変更に抵抗するプログラムを手に入れました。

しかし、そこに欠けているステップがあります。本当の右の順序は次のとおりです。

• 顧客と経営陣と協力して、現実的で測定可能なパフォーマンス指標と目標を設定します。顧客が気にする指標は速度だけではないことを忘れないでください。
• プロジェクトの現在の状態を目標に対して追跡できるテストハーネスを実装する
• コンパイルする
• テストを実行します。目標を達成できなくなった場合は、早めに悪い道を歩んでいた可能性があることを理解してください。科学を使用します。修正できる悪いアルゴリズムを導入しましたか、それとも根本的に間違っていますか？基本的に間違っている場合は、最初からやり直してください。修正できる場合は、バグを入力して、後で戻ってください。
• 正しくする
• テストを再度実行してください...
• エレガントに
• テストを再度実行してください...
• 目標を達成していますか？はいの場合は、ビーチに行きます。そうでない場合は、十分に高速にします。

一般的なルールとして、後でパフォーマンスを最適化するのが最善ですが、開発者がかなりの負荷やデータが追加されたときに遅くなるソフトウェアになったと開発者が認識すると、多くのプロジェクトが悪化するのを見てきました。

ですから、私の意見では、中間的なアプローチが最適です。それにあまり重点を置かないでください。しかし、パフォーマンスを完全に無視しないでください。

私が何度も見た例を示します。ORMライブラリを指定すると、1つ以上のOrderを持つことができるUserエンティティがあります。ユーザーのすべての注文をループして、ユーザーがストアでどれだけ費やしたかを調べましょう-素朴なアプローチ：

User user = getUser();
int totalAmount;
for (Order o : user.getOrders()) {
  totalAmount += o.getTotalAmount();
} 

開発者がその意味を考えずに同様のことを書くのを見てきました。最初にユーザーを取得します。これは、Userテーブルで1つのSQLクエリになることを望みます（ただし、さらに多くのことを伴う可能性があります）。次に、注文のループを実行します。 、製品情報など-これらはすべて、注文ごとに単一の整数を取得するためだけです！

ここでのSQLクエリの量は驚くかもしれません。もちろん、エンティティの構造に依存します。

ここで、正しいアプローチは、ORMが提供するクエリ言語で記述された別のクエリを介してデータベースから合計を取得する別の関数を追加することである可能性が最も高いため、これを延期せずに最初に行うことを推奨します後で そうした場合、おそらくあなたは世話をするより多くの問題を抱えることになり、どこから始めればよいかわからないからです。

総システムパフォーマンスは、システムコンポーネント全体の複雑な相互作用の結果です。それは非線形システムです。したがって、パフォーマンスは、コンポーネントの個々のパフォーマンスだけでなく、それらの間のボトルネックによっても制限されます。

システムのすべてのコンポーネントがまだ構築されていない場合、明らかにボトルネックをテストすることはできません。そのため、実際には早期にテストすることはできません。一方、システムを構築した後は、必要なパフォーマンスを得るために必要な変更を加えるのはそれほど簡単ではないかもしれません。したがって、これは骨付きCatch-22です。

問題をより難しくするために、実稼働のような環境に切り替えると、パフォーマンスプロファイルが大幅に変わる可能性があります。

それで、あなたは何をしますか？まあ、いくつかのこと。

1. 実用的である。早い段階で、パフォーマンスの「ベストプラクティス」であるプラットフォーム機能を使用することを選択できます。たとえば、接続プーリング、非同期トランザクション、およびステートフルネスの回避を利用します。ステートフルネスは、異なるワーカーが共有データへのアクセスを争っているマルチスレッドアプリケーションの停止になる可能性があります。通常、これらのパターンのパフォーマンスをテストするのではなく、何がうまく機能するかを経験から知っているだけです。

2. 繰り返します。システムが比較的新しい場合は、ベースラインのパフォーマンス測定を行い、ときどき再テストして、新しく導入されたコードがパフォーマンスを過度に低下させないことを確認します。

3. 早期に過度に最適化しないでください。何が重要になり、何が重要にならないのか、あなたは決して知りません。たとえば、プログラムが常にI / Oを待機している場合、超高速の文字列解析アルゴリズムは役に立たない場合があります。

4. 特にWebアプリケーションでは、パフォーマンスよりもスケーラビリティに重点を置くことができます。アプリケーションがスケールアウトできる場合、十分に高速になるまでノードをファームに追加し続けることができるため、パフォーマンスはほとんど問題になりません。

5. データベースには特に注意が必要です。トランザクションの整合性の制約により、データベースはシステムのあらゆる部分を支配するボトルネックになる傾向があります。高性能システムが必要な場合は、データベース側で作業し、クエリプランをレビューし、一般的な操作を可能な限り効率的にするテーブルおよびインデックス構造を開発する有能なスタッフがいることを確認してください。

これらの活動のほとんどはプロジェクトの開始または終了のためではありませんが、継続的に出席しなければなりません。

私はジュニアソフトウェア開発者であり、パフォーマンス（速度）を向上させるためにソフトウェアを最適化するのに最適な時期はいつになるのか疑問に思っていました。

2つの非常に異なる極値があることを理解してください。

最初の極端な例は、高度なJITを実装するかどうかにかかわらず、作業をいくつのプロセスやスレッドに分割するか、ピースが通信する方法（TCP / IPソケット？直接関数呼び出し？）など、設計の大部分に影響を与えるものですまたは、「一度に1つのオペコード」インタープリター、またはSIMDに適したデータ構造を計画するかどうか、または...

もう1つの極端な点は、マイクロ最適化です。至る所に小さな微調整があります。これらのことは、実装にほとんど影響を与えない傾向があり（多くの場合、コンパイラーがとにかく行うのが最善です）、気が向いたときにこれらの最適化を行うのは簡単です。

これらの両極端の間には、大きな灰色の領域があります。

結局のところ、「利益はコストを正当化するか」という質問に答えるために使用される経験/経験に基づいた推測です。間違った推測を頻繁に行う場合の極端な最適化では、すべての作業を破棄し、ゼロまたはプロジェクトの失敗から再起動することを意味します（不必要に複雑すぎる設計に時間がかかりすぎます）。もう一方の極端な近くでは、測定（プロファイリングなど）を使用して重要であることを証明できるまで、そのままにしておく方がはるかに賢明です。

残念ながら、私たちは、最適化が「些細な」極端なもの（ほとんど無関係）のみを含むと考える人があまりにも多い世界に住んでいます。

性能も保守性もないコードを記述するのが最も簡単です。性能の高いコードを書くことは困難です。保守可能なコードを記述することはまだ困難です。そして、保守可能でパフォーマンスの高いコードを記述することは最も困難です。

ただし、パフォーマンスの高いコードを保守可能にするよりも、保守可能なコードのパフォーマンスを向上させる方が簡単です。

今、明らかに、それはあなたが作っているシステムのタイプに依存します、いくつかのシステムは非常にパフォーマンスが重要で、最初から計画されたものを必要とします。上記で回答したEric Lippertのような非常に才能のある人々にとって、これらのシステムは一般的かもしれません。しかし、私たちのほとんどにとって、それらは私たちが構築するシステムの少数派です。

ただし、最新のハードウェアの状態を考えると、ほとんどのシステムでは、最初から最適化に特別な注意を払う必要はなく、通常、パフォーマンスの破壊を回避することで十分です。これが意味することは、単に照会するのではなく、テーブルのすべてのレコードを戻してカウントを取得するなど、明らかに愚かなことをしないことselect count(*) from tableです。間違いを避けて、使用しているツールを理解する努力をしてください。

次に、コードを保守可能にすることに最初に焦点を合わせます。これにより、私は意味する：

1. 懸念事項をできる限り厳密に分離します（たとえば、データアクセスとビジネスロジックを混在させないでください）
2. 可能な場合、具象型ではなく抽象型を参照する
3. コードをテスト可能にする

保守可能なコードは、統計が必要であることが示されている場合、最適化がはるかに簡単です。

次に、コードに多数の自動テストが含まれていることを確認します。これにはいくつかの利点があります。バグが少ないと、必要なときに最適化する時間が長くなります。また、最適化を行うと、実装のバグをより迅速に見つけることができるため、最適なソリューションをより迅速に反復して見つけることができます。

自動化された展開スクリプトとスクリプト化されたインフラストラクチャもパフォーマンスチューニングに非常に役立ちます。これも繰り返し実行できるためです。他の利点は言うまでもありません。

そのため、いつものように、例外もあります（より適切に識別するには経験が必要です）が、一般的に、私のアドバイスは次のとおりです。次に、コードが保守可能であることを確認してください。第三に、自動化されたテスト。4番目に、完全に自動化された展開。これらのことを行った後にのみ、最適化について心配する必要があります。

画像処理やレイトレーシングなど、パフォーマンスが非常に重要な領域での作業に偏っているかもしれませんが、「できるだけ遅く」最適化することは今でも言いたいです。要件がパフォーマンスにどれほど重要であっても、測定した後は、事前よりも後知恵で常にはるかに多くの情報と明確さがあります。つまり、最も効果的な最適化でさえ、そのような知識を得た後、通常適用されます。

特異なケース

しかし、時々、「可能な限り遅く」は、いくつかの特殊なケースではまだかなり早いです。たとえば、オフラインレンダラーの場合、パフォーマンスを実現するために使用するデータ構造とテクニックは、実際にユーザーエンドデザインに浸透します。。これはうんざりするように聞こえるかもしれませんが、フィールドは最先端であり、パフォーマンスクリティカルであるため、ユーザーは特定のレイトレーサーに適用される最適化手法に固有のユーザーエンドコントロールを受け入れます（例：放射キャッシュまたはフォトンマッピング）他の人は、レンダリング専用のマシンを備えたレンダーファームをレンタルしたり所有したりするために莫大な金額を費やすことに慣れています。競争力のあるオフラインレンダラーがレンダリングに費やす時間を大幅に削減できる場合、これらのユーザーの時間と費用は大幅に削減されます。これは、時間の5％の短縮が実際にユーザーを興奮させる一種の領域です。

このような特殊なケースでは、ユーザーエンドデザインを含むデザイン全体が使用するデータ構造とアルゴリズムを中心に展開するため、1つのレンダリングテクニックを自由に選んで後で最適化することはできません。ここで、あなたは個人として、そしてあなたの特定の長所と短所は、競争力のあるソリューションを提供することに大きく影響するので、必ずしも他の人にとってうまくいったものでさえも行くことができません。Arnoldの背後にある主な開発者の考え方と感性は、非常に異なるアプローチを使用したVRayに取り組んでいるものとは異なります。彼らは必ずしも場所/技術を入れ替えて最高の仕事をすることはできません（彼らは両方とも産業のリーダーですが）。一種の実験とプロトタイプとベンチマークを行い、自分が何であるかを見つけなければなりません あなたが実際に売れる競争力のある何かを出荷したい場合、最先端の技術の無限の配列を考えると、特に良いです。そのため、この特殊なケースでは、パフォーマンスの問題は、開発を開始する前の最も重要な問題である可能性があります。

それでも者は必ずしも最適化に違反することを「可能な限り遅く」、それだけだ「後半できるだけ」はむしろ早くこれらの極端なと独特の例です。開発者にとって、このような初期のパフォーマンスの懸念をいつ、あるいはまったく必要としないのか、それがまったく必要ないのかを把握することが、おそらく主な課題です。最適化しないことは、すべてを最適化する素朴な開発者を見つけることができないため、開発者のキャリアで学び、学習を続けるための最も貴重なものの1つかもしれません逆生産性にもかかわらず）。

できるだけ遅く

おそらく最も難しい部分は、それが何を意味するかを理解しようとすることです。私はまだ学んでおり、ほぼ30年間プログラミングを行っています。しかし、特に今では30年で、それほど難しくないことに気付き始めています。実装よりも設計に重点を置くのであれば、それはロケット科学ではありません。設計に変更を加えずに後から適切な最適化を行うための余地を残すほど、後ほど最適化できます。そして、生産性が高まるにつれて、そのような余裕のあるデザインを探し求めました。

後で最適化するための呼吸室を提供する設計

実際、これらのタイプの設計は、「常識」を適用できれば、ほとんどの場合達成するのが難しくありません。個人的な物語として、私は趣味として視覚芸術に興味があります（アーティストが自分のニーズを理解し、言語を話すためにソフトウェアをプログラミングすることはいくらか助けになります）。自分の作品を落書きして共有し、他のアーティストとつながる簡単な方法としてオンラインで。

特に私のお気に入りのサイトとアプレットにはパフォーマンス上の欠陥がありました（些細でないブラシサイズはクロールに遅くなります）が、とてもいいコミュニティがありました。パフォーマンスの問題を回避するために、小さな1ピクセルまたは2ピクセルの小さなブラシを使用して、次のように作業を落書きしました。

その間、私はソフトウェアの作者にパフォーマンスを改善するための提案を続けましたが、彼は私の提案がメモリの最適化とアルゴリズムなどについて話している特に技術的な性質のものであることに気付きました。だから彼は実際に私がプログラマーかどうかを尋ね、私はイエスと言って、彼はソースコードに取り組むように私を招待した。

それをプロファイリングし、私の恐怖に、彼はのように、「抽象ピクセル・インターフェース」のコンセプトにソフトウェアを設計していたが、それを実行した、ソースコードを見て、私はとてもIPixelダイナミックですべてのトップホットスポットの後ろに根本的な原因になってしまいました、すべての単一画像のすべての単一ピクセルの割り当てとディスパッチ。しかし、ソフトウェアのデザイン全体を再考せずに最適化する実用的な方法はありませんでしたそしてすべてがこの抽象的なピクセルに依存しています。

これは「常識」の違反だと思いますが、明らかに開発者にとってはそんな常識ではありませんでした。しかし、ピクセル、パーティクル、または巨大な軍隊シミュレーションの小さなユニットのように、最も基本的なユースケースでさえ数百万単位でインスタンス化するような、細かいレベルで物事を抽象化しないようなものです。賛成IImage（あなたはそのかさばる集約レベルで必要なすべての画像/ピクセルフォーマットを扱うことができる）、またはIParticleSystemにIPixelまたはIParticle、その後、あなたが最も基本的かつ迅速に書き込み中に置くことができますし、そのようなインタフェースの背後に、簡単に理解し実装とソフトウェアの設計全体を再検討することなく、後で最適化するために必要なすべての部屋を確保できます。

そして、それが最近私が見ている目標です。上記のオフラインレンダラーなどの特殊なケースを除き、可能な限り遅く最適化するための十分なブリージングルームを設計し、可能な限り多くの後知恵情報（測定を含む）を行い、必要な最適化を可能な限り遅く適用します。

もちろん、一般的なユーザーエンドの場合に簡単でないサイズに簡単に到達する入力で2次複雑度アルゴリズムの使用を開始することを必ずしも提案しているわけではありません。とにかくそれは誰ですか？しかし、実装が後で簡単に交換できる場合、それはそれほど大したことではないと思います。デザインを再検討する必要がない場合でも、それは重大な間違いではありません。

そのパフォーマンスがアプリケーションにとって何を意味するかによります。そして、アプリケーションが機能的に完了する前にパフォーマンスを最適化することさえ可能かどうかについて。

ほとんどの場合、これ以上何もすることがなくなるまで心配する必要はありませんが、アプリケーションの成功には特定のレベルのパフォーマンスが不可欠である可能性があります。それが事実であり、それが簡単ではないかもしれないと疑う場合、「速く失敗する」ためにパフォーマンスを見始めるべきです。

どんなプロジェクトにとっても重要な原則は、最初にハードな部分に集中することです。そうすれば、それができないと判明した場合、早期に知ることができ、まったく違うことを試す時間があるか、プロジェクトに費やしすぎる前にプロジェクトがキャンセルされる可能性があります。

パフォーマンスは速度以上のものであることをお勧めします。スケール（数百から数千の同時ユーザー）が含まれます。確かに、実稼働環境の負荷がかかったときにアプリケーションがタンクに入らないようにする必要があります。パフォーマンスには、アプリケーションが消費するリソース（メモリなど）の量が含まれます。

パフォーマンスも使いやすさです。一部のユーザーは、2回のキーストロークで1秒でタスクを実行するよりも、1回のキーストロークで10秒でタスクを実行したい場合があります。そのようなものについては、設計リードに尋ねてください。私はこのようなものをユーザーに早く持ち込むのは好きではありません。真空では、彼らはXと言うかもしれませんが、彼らが機能的なプレリリースで働いたら、彼らはYと言うかもしれません。

個々の最適な速度は、データベース接続などのリソースを保持することです。ただし、規模を拡大するには、接続をできるだけ遅く取得し、できるだけ早く解放する必要があります。3つのものを取得するためのデータベースへの1回の旅行は、データベースへの3回の旅行よりも高速です。

セッション中に変わらない情報を求めて旅行をしていますか。その場合は、セッションの開始時に取得して保持します。

コレクションの種類を選択するときは、機能、速度、サイズを考慮してください。

コレクション内のアイテムを保持する必要がありますか？一般的な問題は、ファイルからすべての行をリストに読み取り、リストを一度に1行ずつ処理することです。ファイルを一度に1行ずつ読み取り、リストをスキップする方がはるかに効率的です。

1回ループして3つのことを実行できるのに、3回ループしていますか。

コールバックで別のスレッドで処理する必要があるかもしれない場所はありますか。その場合、差し迫った設計ニーズに干渉しない場合、その可能性を念頭に置いてコードをパッケージ化します。

多くのパフォーマンスもクリーンなコードです。

時期尚早な最適化があり、実際にはもっと時間がかからない常識的なことを前もって行うだけです。

データベースでは、時期尚早な最適化が見られます。速度の問題が発生する前に速度を非正規化します。私が得る議論は、後でテーブルを変更する場合、すべてを変更する必要があるということです。多くの場合、データをそのまま表示するビューを作成できますが、非正規化されたテーブルのために後で交換する必要がある場合があります。