理論的には、顧客はソフトウェアのパフォーマンスの向上を直接体験して感じることができるはずです。
実際には、改善が十分に目立たない場合があります。そのため、改善から収益を得るには、顧客を引き付けるためにマーケティングで見積もり可能なパフォーマンス数値を使用する必要があります。
知覚されるパフォーマンス（GUIレイテンシなど）とサーバー側のパフォーマンス（マシン、ネットワーク、インフラストラクチャなど）の違いはすでにわかっています。
プログラマーが他のプログラマーではなく、マネージャーや顧客であるパフォーマンス分析を「作成」するために、プログラマーが余分な時間を費やす必要がある頻度はどれくらいですか？
回答:
が@jwentingは、いくつかの良いポイントを作る、私は一般的な評価に同意する必要があります。
ユーザーは、マイナーなパフォーマンスの改善に気付かないことがよくあります。
それで、私は同意することができます。
私が反対するところはこの声明を中心に展開します：
ほとんどのエンドユーザー向けアプリケーションは、ほとんどの時間をユーザー入力の待機に費やしています。
さて、ジャンプする前に、私もその意見に同意します！ただし、このステートメントは、ユーザーが実際にシステムをどのように認識しているかを十分に理解していない人が見落としがちな事実を強調しています。
ユーザーは、アプリケーションがロードされるのを待つ必要があるときに、アプリケーションが遅いことに気づくでしょう。ユーザーは、データを入力する間にプログラムを一時停止する必要がある場合に、そのことに気付くでしょう。
ソフトウェアのパフォーマンスは、システムとの自然で流動的な相互作用を壊すときに、ユーザーにとって明白です。
ユーザーがシステムのパフォーマンスに気付かないのは、システムが完全に機能していてユーザーを妨げていない場合だけです。
一部のパフォーマンス強化は、パフォーマンスとして認識されません。顧客は、システムが「より良い」と感じることに気づくでしょう。
サブコンシャスはコンシャスよりもはるかに高速で動作します。私たちの脳は即座にフィードバックするようにプログラムされており、一連のタスクに直面したときは、次々とそれらを振り回す必要があります。フィードバックが少し停止すると、このプロセスがばらばらになり、ストレスレベルが増加します。フィードバックに一時停止がある場合、人々はボタンを考えずに自動的にダブルクリックします。
パフォーマンスの改善はごくわずかで、お客様が直接気付くことはほとんどありません。せいぜい、彼らはそれを使用するよりも少し流暢なアプリケーションフローを持っているかもしれませんが、意識的に気づかれるには十分ではありません。
ほとんどのエンドユーザー向けアプリケーションは、ほとんどの時間をユーザー入力を待つのではなく、その入力を処理するのに費やしていることに注意してください。そのため、ボタンのクリックを処理して画面を更新するために必要な100ミリ秒を10％削ったとしても、ユーザーは更新された画面でさらに10000ミリ秒間何もしないので、ほとんど気付かないでしょう。
誰が気づくかは、2時間かかっていたバッチジョブが90分で完了するようになったバッチジョブを見たシステム管理者ですが、結果を待って怒る必要がある場合は、より速いリターンで途中で中断されます。彼の映画を通して:)
私はここに飛び込んで異常なケースを提供したかっただけです...
* パフォーマンスに関する注意が必要なお客様は、わずかな変更でも通知してください！。
私が担当しているのは、顧客自身によるパフォーマンスの観点から死に至るまで分析される傾向のあるプロダクションレンダリングです。マイナーバージョンよりもパフォーマンスが2％遅くなるのは、「バグレポート」の形でまとめて報告されるスローダウンと同じです。
フォーラムのスレッドは、多くの場合、顧客が開発者自身よりも実際にベンチマークを行っているさまざまなバージョンのソフトウェアに対してシーンをベンチマークすることから始まります。「このシーンは、バージョンXでのレンダリングに1時間40分かかりました。バージョンYでは32分かかります。」
「このシーンはバージョンXでのロードに18分かかりましたが、バージョンYでのロードには4分かかりました。」
これらは、最適化が適用されたときに非常に高く評価され、それだけでソフトウェアの新しい非常に高価なアップグレードの購入を保証するのに十分であり、時には10％の削減のようなわずかな改善しかありません。
一部の大規模なスタジオでは、製品を高速化するときに顧客に莫大な費用を節約することもできます。これは、大規模なスタジオの一部はレンダーファームを使用するため、1日中何百ものマシンをレンダリングするために支払う必要があり、ここでの時間の改善により、制作プロセス全体をスピードアップします（アーティストがレンダリングするのを待つのではなく、アーティストの生産性が高い場合は、より良い結果が得られることもあります）。
したがって、顧客が本当に、本当に、本当に気づくこのようなフィールドが存在します-時には開発者自身よりもさらに多く、これはスループットよりもレイテンシに関するUIインタラクションの概念の外にあります。
プログラマーが他のプログラマーではなく、マネージャーや顧客であるパフォーマンス分析を「作成」するために、プログラマーが余分な時間を費やす必要がある頻度はどれくらいですか？
私たちのケースでは、常に、ほぼすべてのマイナーリリースが行われています。速度はトップセールスポイントの1つであり、最も技術的なベンチマークやパフォーマンス分析でさえ、実際に顧客やマネージャーに高く評価され、理解されています。多くの場合、顧客の認識は狂った狼のようであり、より多くの最適化に飢えています。そして、物事をより速くする方法について開発者に提案しようとしています。この場合、さらに最適化し、保守性や機能拡張などの他の指標に焦点を合わせるという顧客の衝動に抵抗するには、実際には規律が必要です。
私が遭遇する唯一の時間は：
プログラマーが他のプログラマーではなく、マネージャーや顧客であるパフォーマンス分析を「作成」するために、プログラマーが余分な時間を費やす必要がある頻度はどれくらいですか？
業界にかかっていると思います。奇妙な防衛契約の世界では、これはかなり頻繁に行われます。製品を特定の方法で実行させるための特定の要件があります。これらのパフォーマンスメトリックは、エンドユーザーが体験したことに直接関連しているとは限りません。そして、私たちは通常、製品がどこに底を打っているかを確認するために独自のテストを行います。どちらのタイプのテストも、レポートにまとめられ、その意味について真剣に考えられています。
とはいえ、顧客や展開ベースがあまり専門的でない状況（つまり、商業の世界）でそれが当てはまるかどうかはわかりません。パフォーマンス仕様を満たす必要のあるCOTSを購入していることを考えると、一部の購入者はそのようなパフォーマンス仕様を求めていると言えますが、私の経験では、これまで行ってきたCOTS企業はパフォーマンス分析のホワイトペーパーをあまり多く持っていません。利用可能です。それは、業界、会社の規模、および競争の性質に依存するようです。ああ...資本主義。
私の意見では、パフォーマンスの向上が目立たない場合、市場性はありません。言い換えると、明らかに改善されていないソフトウェアに対して、誰かがより多くを支払うのはなぜですか？
目立たないパフォーマンス改善のマーケティングの主張は、一般的にユーザーがそのような主張にほとんど重みを与えていないように思います。たとえば、分散バージョン管理の使用を開始したいときは、違いは無視できると信じていたため、gitパフォーマンスの主張を無視しました。特にinotifyのサポートと組み合わせると、自分で試してみただけで信頼できることがわかりました。
エンドユーザーエクスペリエンスに直接関連しないパフォーマンスの向上については例外を設けます。たとえば、サーバーのスループットは、エンドユーザーが違いに気付かなくても、サーバーを購入して保守する人にとって重要になります。その場合、単純な「Xに対する改善率」で十分です。
Thread.Sleep(1000); //pretend this does more than change a 0 to a 1 in the database.