実行中のシステムのパフォーマンスを理解することは、デバッグを学習するのと同じ理由から避けられません。あなたが書いたコードのコストを完全に正確に理解していても、あなたのコードは、あなたがほとんど制御できないか可視である他のソフトウェアシステムを呼び出すでしょう。しかし、実際には、パフォーマンスの問題は一般的にデバッグよりも少し異なり、少し簡単です。
あなたやあなたの顧客が、システムやサブシステムの速度が遅すぎると考えているとします。速くしようとする前に、なぜそれが遅いのかの精神モデルを構築する必要があります。これを行うには、プロファイリングツールまたは適切なログを使用して、時間やその他のリソースが実際に費やされている場所を特定します。その時間の90％がコードの10％に費やされるという有名な言葉があります。私はそれにパフォーマンスの問題に対する入出力費用（I / O）の重要性を追加します。多くの場合、ほとんどの場合、I / Oはある意味で費やされます。高価なI / Oとコードの高価な10％を見つけることは、あなたのメンタルモデルを構築するための第一歩です。
コンピュータシステムの性能には多くの次元があり、多くのリソースが消費されます。測定する最初のリソースは、* wall-clock time です。これは、計算に必要な合計時間です。ロギングウォールクロック時間*は、他のプロファイリングが実用的でない状況で起こる予測不可能な状況について通知できるため、特に重要です。しかし、これは必ずしも画像全体を表すとは限らない。場合によっては少し時間がかかりますが、実際に処理しなければならないコンピューティング環境では、非常に多くのプロセッサ秒を消費するものはずっと良いでしょう。同様に、メモリー、ネットワーク帯域幅、データベースまたは他のサーバーへのアクセスは、最終的にプロセッサ秒よりもはるかに高価になる可能性があります。
同期化された共有リソースの競合は、デッドロックと飢餓を引き起こす可能性があります。デッドロックは、不適切な同期やリソース要求のために処理できないことです。飢餓とは、コンポーネントを適切にスケジュールすることではありません。それがすべて期待できる場合は、プロジェクトの開始時からこの競合を測定する方法があることが最善です。この競合が起こらなくても、それを自信をもって表明できることは非常に有用です。