私の意見では、そのような状況は、「時期尚早」という概念の境界が非常に曖昧で直感的であるために発生します。まるでフランスパンのジューシーさのような経験的でとらえどころのないものです。
原則として、プログラム、アルゴリズム、およびそれらの最適化のアーキテクチャに関連するいくつかの経験的概念を操作することはかなり奇妙ですが、これらは非常に測定可能なものです。 これは、最適化の適時性を簡単に測定できることを意味します。 これについてお話します。
最適化とは何ですか？
簡単に言えば、最適化とは、パフォーマンスパラメータ（実行時、リソース消費、帯域幅）の観点から、プログラムを「満たされていない」状態から「満たされた」状態に減らすことです。 つまり 私たちはどの指標が私たちに合っているかを知っており、プログラムがそれらに到達していないことがわかったら、それを最適化する時です。
時期尚早な最適化とは何ですか？
私たちが「満足していない」状態にあると思うが、実際にはすべてに「満足」している場合、私たちは時期尚早に最適化します。
タイムリーな最適化とは何ですか？
私たちは、このプログラムが既に/「やろうとしている」/「ならない」ことを知っています-そして私たちは状況を修正するための措置を取っています。
理想的な世界では、要件を満たすプログラムを作成し、自由にリリースします-そして、すべてがすぐに「私たちに合っています」。 現実の世界ではよくあることですが、私たちは皆よく知っています。
幸いなことに、タイムリーに最適化するのか、時期尚早に最適化するのかを理解するには、同じアクションを実行する必要があり、通常は1枚の用紙で十分です。
測定可能な適時性
一般に、適時性/未熟さの測定自体は、非常に単純なアクションを必要とします。
- パフォーマンス要件を取る
- プログラムがこれらの要件に適合するかどうかを計算する
- 積み上げられている場合-幸せに暮らしています。 そうでなければ、プログラムを最適化する
最も一般的な要件は応答時間であるため、スループットはそれに応じて減少し、リソース消費は別の大きなトピックであるため、最初に集中します。
したがって、必要なプログラム実行時間-TVおよびパスごとに必要な処理済みデータ数-TDがあります。
私たちはプログラムを設計または開発しているだけで、何かが最適に進んでおらず、時期尚早な最適化の恐れがあると感じています。 感覚を測定し、恐怖症の発症を防ぐには、次の手順を実行する必要があります。
- 定数を考慮して、設計/開発されたO（n）アルゴリズムの時間の複雑さを決定します。 3 * n so 3 * n、n * logn + nなど 正確であればあるほど良いです。
- 時間の複雑さを説明する関数にAPを代入して、 パス-TOごとに実行される操作の数を取得します。
- TBに基づいて、1 つの要素-入力配列のSVE （最上位エンティティ、1つのドキュメント、1人のユーザー）の平均許容処理時間を計算します。 つまり
SVE = TB / KO
- さらに、 1つの要素の実際の処理時間 <= 1つの要素の平均許容処理時間であることを確認し、必要に応じて、スタックの上位に位置するプログラム/アルゴリズムに対してステップ1と2を繰り返します。
簡単な例を見てみましょう
100レコードを処理し、2秒以内に収まるプログラムを作成する必要があるとします。 開発中に、時間の複雑度がO（n ^ 2）である特定のアルゴリズムを思いつきました。
この場合、各レコードを処理するのに平均で2/100 ^ 2 = 2 * 10 ^ -4秒（0.2ミリ秒または200マイクロ秒）があります。 これは単純なアクションを実行するのに十分です（ このインフォグラフィックで判断すると、算術演算とメモリアクセスには数十から数百ナノ秒かかります）が、どのような種類のネットワークインタラクションも使用できなくなります。
つまり そのような要件のために数字の配列の並べ替えを記述する場合-"満足"であり、100個のSOAPリクエストを送信する必要がある場合-"不満"であり、何かを考え出すときです。
おわりに
一般に、このアプローチは簡単に拡張でき、適時性の上限を簡単に評価し、不確実性を排除し、作成されるプログラムの有意性を高めます。 そして最も重要なことは、本番環境での書き込みが少なくなるため、ユーザーとマネージャーを幸せにします。
当然のことながら、このアプローチでは商用運用を開始するには不十分です。したがって、ストレステストを拒否する前に専門家に相談してください。
ご清聴ありがとうございました！