ほとんどのソフトウェアプロジェクトは、最初にリリースされたときよりも10?100倍の速度で比較的簡単に作成できます。市場投入までの時間を迫られる中で、単純かつ迅速に作業を行うソリューションを選択することは、賢明で効果的ですが、他のソリューションより効率的ではありません。しかし、パフォーマンスはユーザビリティの一部であり、しばしば最終的にはより慎重に検討する必要があります。
非常に複雑なシステムのパフォーマンスを向上させるための鍵は、ボトルネック*やリソースの大部分が消費される場所を見つけるのに十分に分析することです。計算時間のわずか1％を占める関数の最適化にはあまり意味がありません。経験則として、システムやシステムの重要な部分を少なくとも2倍速くすると思わない限り、何かをする前に慎重に考える必要があります。通常これを行う方法があります。変更に必要なテストと品質保証の努力を検討してください。それぞれの変更によってテストの負担がかかりますので、いくつかの大きな変更を加える方がはるかに優れています。
何かを2倍に改善した後は、システムの中で次に高価なボトルネックを発見するために少なくとも再考し、再分析する必要があります。
多くの場合、パフォーマンスのボトルネックは、頭を数える代わりに、足を数え、4で割ることによって牛を数える例になります。たとえば、リレーショナルデータベースシステムに適切なインデックスを付けることができず、多くの検索を行うと、少なくとも20倍遅くなるなどのエラーが発生しました。他の例としては、内部ループで不必要なI / Oを実行し、不要なデバッグ文を残したり、不必要なメモリ割り当て、特にパフォーマンスに関して文書化されていないライブラリやその他のサブシステムを使用することが挙げられます。この種の改善は時々「低掛けの果実」と呼ばれ、いくつかの利点を提供するために簡単に選ぶことができます。
ぶら下がっている果物が足りなくなってから、あなたは何をしますか？さて、あなたはもっと上に行くことができる、または木をチョップする。小さな改善を続けることも、システムやサブシステムを真剣に再設計することもできます。 （これは、新しい設計だけでなく、上司にこれが良い考えであることを納得させる良いプログラマーとしてのあなたのスキルを使用する絶好の機会です。）しかし、サブシステムの再設計について論じる前に、あなたの提案がそれを5?10倍良くするかどうかにかかわらず、 Next How to Optimize Loops