(これと重複する質問を提供してください。見つからなくて残念です。)
私の開発マシンは「遅い」です。私はそれを「たくさん」待っています。
その時間を公正かつ正確に測定するのを手伝いたいという意思決定者から、私は尋ねられました。コンピューターでの待機時間 (コンパイル中、毎日アプリが開くのを待つ時間など) をどのように定量化しますか?
この種のことを効果的に報告するソフトウェアはありますか? これを特にうまく捉えて伝達するOSメトリック（I / O何か、ページファイルスワッピング頻度など）はありますか？テストすることをお勧めする何らかのベンチマークはありますか?
編集:私は C# (主に ASP.NET) を書いています。
上層部が感銘を受けるかもしれない 1 つの指標を次に示します。アプリケーションのビルドにかかる平均時間と、1 日あたりのビルド回数を測定してください。たとえば、最終的には 1 日あたり 100 ビルドまで、それぞれ 60 秒でした。ここで、おそらくより高速なマシンで平均ビルド時間を測定します (ビルドごとに 30 秒とします)。
この時点で、「より高速な」マシンを使用するとどれだけの時間を節約できるかがわかります。開発者ごと、日ごと。開発者の数と 1 か月の日数を掛けると、チームに別の開発者を追加することに対して、これがどのように積み重なるかがわかります。はい、知っています。チームに人員を追加する際には他にも考慮事項がありますが、これは「上層部」が関連できる大まかな比較になります。たとえば、全員がより高速なマシンを使用していれば、ビルドに費やす時間が短縮され、開発者が 1 人増えることに匹敵します。
一方で、全員のマシンをアップグレードするためのコストを適切に見積もる必要があります。
可能であれば、このタイプの比較を複数の「より高速な」マシンに対して実行して、それらの相対的なパフォーマンスを判断し、直面しているボトルネック (RAM 対 CPU 対 I/O ?) を個別化する必要があります。
最後に、私の個人的な見解は、この種のプロセスとその後の利害関係者との話し合いが行われている間 (時間がかかる場合があります)、全員をより大きく/より多くのモニターにすることができるということです。これは比較的安価なアップグレードであり (もちろん、52 インチ LCD モニターを購入する場合はそれほど安くはありませんよね?)、モニター資産を増やすと生産性が向上します (利点: 従業員の士気も向上し、生産性が向上します)。
HTH
FireFox を閉じて、メモリを確保します。RAM を追加します。とても助かりました。
測定/比較するものが何もない場合、定量化は困難です。あなたの dev-box が 100,000 行のコードのプロジェクトをコンパイルするのに 12 分かかり、測定する他の dev-box がない場合、これが良いか悪いかわかりません。たぶん、100,000 行で 12 分が実際に良いのでしょうか?
それを測定しても役に立たず、意思決定者の役に立たないことは確かです。検討; 「はい、ボス、私たちのプロジェクトをコンパイルするのに平均 12 分かかります。」上司は言います。「えっ、それって普通ですか？」あなたは何もわかってない。
コンピューターのハードウェアは安価です。開発ボックスを見て、パフォーマンスを改善するために意思決定者にいくらかの現金を投入するよう依頼することを検討してください。1 日に平均 5 回コンパイルし、1 回のコンパイルに平均 12 分かかる場合、それは毎日 1 時間の損失であり、1 週間で最大 5 時間の損失になります。いくらかの RAM や CPU のアップグレードのコストに見合うだけの価値があります。
作業環境により異なります。たとえば、Visual Studio (C++、2005) では、IDE が通常のビルド出力の後に経過時間を出力するように、時限ビルドを実行できます。
私にとっては、遅いマシンは予想外のスローダウンほど生産性を損なうことはありません.F5を押すたびにマシンがソリューション全体を12分でコンパイルする場合、マシンではなくソリューションに問題があります. その上、12分で問題ありません。起きて休憩できます。休憩の長さを知っていて、コントロールできるときに休憩を取るのは実際には良いことです.
私が最も生産性を損なっていると感じたのは、ウィルスのスキャン (またはアップデートのインストール) を勝手に開始するこれらの協力ソフトウェアです。