私の質問:パフォーマンステストは通常、アプリケーションがさまざまなモジュールと統合され、デプロイの準備ができた後に実行されます。
開発段階でパフォーマンスのボトルネックを特定する方法はありますか。コード分析は@パフォーマンスのヒントを投げますか?
私の質問:パフォーマンステストは通常、アプリケーションがさまざまなモジュールと統合され、デプロイの準備ができた後に実行されます。
開発段階でパフォーマンスのボトルネックを特定する方法はありますか。コード分析は@パフォーマンスのヒントを投げますか?
それはすべて、コード分析中に実行するルールに依存しますが、CAだけでパフォーマンスのボトルネックを防ぐことはできないと思います。
私の期限切れから、パフォーマンスの問題は通常非常に複雑であり、実際の問題を見つけるにはパフォーマンステストを実行する必要があるようです。
一般的には、いいえ。ただし、経験から、これまでに見たことのないシステムを調べて、パフォーマンスの問題が発生しやすいいくつかの設計アプローチを認識することができます。
コードの行数またはクラス数の観点から、それはどのくらいの大きさですか?これは、過剰設計によって引き起こされるパフォーマンスの問題と強く相関しています。
抽象化レイヤーはいくつありますか?各レイヤーは、必要以上のサイクルを費やすチャンスであり、特に各操作が「かなり効率的」であると認識されている場合、この効果はさらに複雑になります。
合意を維持する必要がある個別のデータ構造はありますか?もしそうなら、これはどのように行われますか?通知を介してデータ構造を緊密に同期させようとする試みがある場合、それは危険信号です。
システムへの入力情報のカテゴリのうち、一部は低頻度で変化しますか?もしそうなら、それは「解釈」ではなく「コンパイル」されるべきである可能性があります。これは、パフォーマンスと開発の容易さの両方で大きなメリットになる可能性があります。
一般的なモチーフは次のとおりです。プログラマーAは、情報の適切なチャンクを収集するためのDBアクセスなど、複雑な操作をラップする関数を作成します。プログラマーAは、これが他のプログラマーにとって非常に有用であると考えており、これらの関数がカジュアルではなく、特定の点で使用されることを期待しています。プログラマーBは、これらの強力な関数を高く評価しており、1行のコードで多くのことを実行できるため、これらの関数を頻繁に使用します。(プログラマーBとAは同じ人物である可能性があります。)これがパフォーマンスの問題を引き起こす方法を確認できます。特に、複数のレイヤーに分散している場合はそうです。
これらが最初に頭に浮かぶことです。
いいえ。ただし、ごくわずかな場合を除きます(たとえば、Javaの場合、文字列の追加ではなく、ループでStringBuilderを使用します)。
その理由は、関連するデータセットを使用してアプリケーション全体を実行するまで、特定のコードがアプリケーション全体にどのように影響するかがわからないためです。
例:半ダースの要素のリストを一貫してソートしている場合、バブルソートをクイックソートに変更しても、アプリケーションに大きな影響はありません。または、ソートを1回実行している場合、深夜に実行しても、他の処理が遅れることはありません。
.NET について話している場合は、はい/いいえ... FxCop (または組み込みのコード分析) には、パフォーマンスの問題に対処する多くの規則があります。ただし、このリストはかなり短く、本質的に制限されています。
そうは言っても、FxCop を拡張して、潜在的な問題領域を検出し、フラグを付けるためのより多くのルール (ヒューリスティックまたはその他) を使用できない理由はありません。(私が知っている) 誰もこれに (まだ) 多大な労力を費やしていないというのは、単純な事実です。