ソフトウェアをより速く実行するために、誰もがアイデアを試すことができる期間を促進しますか？

場合によっては、方法論的で徹底的な検索からソフトウェアパフォーマンスのトリックが見つかります。時々、クレイジーなアイデアを試すには発散的な思考と勇気が必要です。時には、アイデアは単なる始まりに過ぎず、多くの努力を払う必要があります。

私たちが取り組んでいるソフトウェアのパフォーマンスを向上させるために、誰もがさまざまなアイデアを試すことができる期間を育成する方法は？チームの全員が少なくとも数か月間ソフトウェアを使用した経験があり、非常に優れています。

発散的思考がソフトウェアのパフォーマンスを改善する方法を見つけるのに役立つことに同意しますか？どうして？何故なの？

最適化のアイデアをすばやく試すことができるテクニックは何ですか？トライアウトから良い結果を得るには、速いコーディング速度が必要ですか？

最後に、緩む可能性を生じさせずに良好な結果を保証するために、どれだけの「時間」を割り当てる必要がありますか？

「より高速な方法」が存在することを証明するには、実験が必要ですか？（2011-06-07を追加）

関連：

• チームのレベルを巧妙に改善するための戦略は何ですか？
• コードハッキングが悪化するのはいつですか？

（賞金目的のみ -2011/06/07チームサイズは2〜4人の開発者で、専用のQAはありません。すべてのコード、ユニットテスト、パフォーマンステストは開発者が行います。プロジェクトの性質により、プロファイラの結果は単一のボトルネックが明らかにならない場合でも、比例した実行時間。）

最善の策は、プロファイラーでホットスポットを特定し、チームとしてホットスポットを修正する方法について話し合うことです。

改善を測定し、文書化できる必要があり（したがって、単なる推測ではありません）、チームとしてそれを行うことで、人々が修正されていることと方法を確実に知ることができます。

プログラマーがコードベースを大胆にハックしてアイデアを試しているということは、何が起こっているのか、それが機能するかどうかを制御できないことを意味します。

プログラマーはスマートで創造的である傾向があります（これらはプログラミングが得意であるための前提条件であるため）ので、問題を解決しようとするときに幅広いアイデアを試すことができるのは常に良いことです。ただし、パフォーマンスを改善しようとするときに覚えておくべき重要なことが2つあります（「パフォーマンス」とは、実行速度を低下させることを意味します）。

• アルゴリズムの最適化は、他の何よりもうまく機能する傾向があります。取るに足らない例として、バブルソートの実装に何をするにしても、十分な数があれば、クイックソートの実装は非常に遅くなり、最終的には高速になります。
• パフォーマンスに関連する何かを行うことは、結果に基づいて何を測定（プロファイル）して何も基にしない限り、まったく無意味です。

私の主なポイントは、野生の実験の期間を開始する前に、これらのことに関して全員と同じページにいることを確認することが重要です。経験の浅い同僚が、決してうまくいかないことを試みていたことを知ることは、常に恥ずべきことです（そして、あなたは彼らに前もってそれを伝えたかもしれません）。

悲しいことに、私は経験から話すことができません。しかし、アトラシアンは1日だけで、従業員が自分のことを何でもやりたいと思って、ある種のパーティーの雰囲気の中でアイデアを発表できると聞いた。どうやら彼らにとってはうまくいったようです。しかし、アンダーセンに同意し、パフォーマンスに関して言えば、どのプロセスが最も時間がかかるかをプロファイリングするよりも、独創的で独創的なアイデアは重要ではないと言う必要があります。おそらく、システムのプロファイルを作成したら、プロセスの重要なセクションをスピードアップする方法についてのアイデアを思いつくために、全員に1日を与えることができます。アイデアを提示した後、どのアイデアを試すかを選択できます。

以前のチームで行った成功したプラクティスの1つは、Deep Divesのコンセプトを持つことでした。数人が会議室に集まり、ユーザーシナリオを決定し、コードのステップ実行またはプロファイラーログの確認を開始します。場合によっては、データがボトルネックを明確に示していたため、懐疑論者が自分のコードに実際にパフォーマンスの問題があることを確信させることができました！これを成功させるために、私たちが従ったいくつかの重要な教義がありました。

1. ボトルネックが疑われるクリティカルシナリオまたはコードパスに焦点を合わせてください。最適化する必要のないものを最適化するのに時間を無駄にしないでください（壊れていない場合）
2. グループを小さく保ち、コードを最もよく知っている人々に焦点を合わせます。機能のテスターとプログラムマネージャーを含めることを忘れないでください-彼らは重要な洞察を持ち、参加するか、より良いテスト方法に関する情報を収集することのいずれかから恩恵を受けることができます。
3. エリアの所有者に高レベルのアーキテクチャブロックレベル図とエリアの概要を提供してセッションを開始します。主要なコンポーネントとは何か、それらが何をするのかを簡単に説明します。コードを掘り下げると、ブロック線図が現実を何回も反映しなかったことに驚くでしょう。（実際の引用：「私たちがまだそのコンポーネントを使用していることを知りませんでした。その数年前に私たちは取り除いたと思いました！」）
4. 機能的なバグとパフォーマンスの問題を見つけることを期待してください。よかったです。また、時には、重要なものが見つからないことを期待してください。それも良いことです。
5. いくつかの長いセッションが予定されています。これらは作業会議です。快適になり、作業を進めてください。全員が協力してストレッチを延長できると、さらに多くのことができます。
6. メモを取って、良いメモを。欠陥追跡データベースを使用する場合は、優先度が低い場合でも、問題をすぐに開いて追跡することを検討してください。

チーム全体が「パフォーマンスプッシュ」に参加しないようにします。これらは通常、ThorbjørnRavn Andersen が別の回答で言及した理由のために、経営者が期待する結果を持ちません。一部の分野で大きな利益を得、人々が馴染みのない他の分野で退行し、「完了」と言うべき利益を予測/追跡することは困難です。それは経営陣とのやりがいのある会話です。

ソフトウェアの速度を改善する必要がある理由は、その中の何かが著しく遅い場合です。そうでない場合、最適化は時間の無駄です。しかし、何かが遅い場合は、タスクを実行してください。

...タスクを実行するには、次の2つの手順があります。

1. タスクを実行している関数が効率的に記述されているかどうかを確認してください。良いまたは悪いアルゴリズムがありますか？効率的な方法でデータベースにアクセスしていますか？一度にできるのに100回ループしますか？多くの場合、コードを簡単に検査することで、1つの障害を見つけてそれを修正できるだけでなく、より優れたプログラマーになることができます。

2. 番号1に1時間以上費やさないでください。1時間以内に問題が見つからない場合は、プロファイラーを使用して問題のスポットを見つけてください。問題点がわかったら、番号1に戻ってもう一度実行し、特定したコードを改善する最適な方法を見つけ出します。

一般的に（**）、実験によってパフォーマンスが向上することはありません。

あなたはそれを手に入れます

• シンプルで効率的な設計を開始する方法を知っている。この部分を間違えたとしても、実験によって大きな違いは生じません。たとえば、コードジェネレーターを使用することが成功するデザインアプローチであるかどうかを判断する方法を知ってください。

• a）パーセンテージベースで高価であり、b）より良いものと交換可能なアクティビティを見つけることによってソフトウェアを調整する方法を知っている。「プロファイラーを使用する」必要があることは誰もが知っていますが、それだけでは十分ではありません。

他の質問に対するこの回答を確認してください。

**例外は、グラフィックレンダリング、プロセッサパイプライン、CUDAの動作など、ハードウェアに依存する厳密なコード、またはネットワークまたはDBプロトコルの実験など、最適な使用方法を習得する必要がある場合です。

追加：大規模システムの多くのプログラマーが驚くべきことに気づくことがあります。大規模で完全に適切に構成されたプログラムでは、目に見えない大規模なパフォーマンスの問題が発生する可能性があり、プロファイラーはルーチンにローカライズされていないため、それらを見つけることができません。プログラムは非常に最適なスタイルで実行されますが、これらはプログラムの一般的な構造の一部です。

具体例を示すために、ソースコード（C ++）を使用してジョブを実行するプログラムを次に示します。これは、私が取り組んだ実際のCプログラムから抽出したものです。

意図したとおりに動作しますが、実際に必要な時間は何分の一ですか？どのくらい高速化できますか？

まあ、プログラムの最初のバージョンでは、完全に合理的で非ローカルな（プロファイラーには見えない）時間が33.3％かかっていました。それが置き換えられたとき、その時間が節約され、それがプログラムの2番目のバージョンでした。

プログラムの2番目のバージョンでは、削除できる他の何か（プロファイラーには見えない）は16.7％の時間を要していました。削除するとバージョン3になりました。

バージョン3では、13％が削除されました。残ったもののうち、66％が削除されました。その後残ったもののうち、61％が削除されました！

そして最後に、その後残ったもののうち、98％が削除されました！

それで、全体像は何ですか？元のプログラムで費やされた1000サイクルごとに、いくつが削除されましたか？998！

すべてのプログラムは異なりますが、私の経験では、すべての大規模なプログラムには、プロファイラーが見つけることができない一連の時間のかかる問題があり、手動サンプリングがあり、プログラマーが本当に最高のパフォーマンスを求めている場合は削除できます大幅な高速化のため。