1

プロパティ値をキャッシュするのに最適な時期と場所については、いつも疑問に思っていました...以下のように、非常に単純に見えるものもあります...

public DateTime FirstRequest {
    get {
        if (this.m_FirstRequest == null) {
            this.m_FirstRequest = DateTime.Now;
        }
        return (DateTime)this.m_FirstRequest;
    }
}
private DateTime? m_FirstRequest;

しかし、もっと複雑な状況についてはどうでしょうか？

  1. データベースから取得された値ですが、選択された後もtrueのままです。
  2. 組み込みキャッシュに保存され、時々期限切れになる可能性のある値。
  3. 最初に計算する必要がある値は？
  4. 初期化に時間がかかる値。0.001秒、0.1秒、1秒、5秒???
  5. 設定されている値ですが、他の何かが来てnullに設定し、再入力する必要があることを示すフラグを立てる場合があります。
  6. ??? 無限の状況があるようです。

プロパティがそれ自体を処理できなくなり、代わりにその値を設定するために何かが必要になるという点は何だと思いますか？

[編集]

最適化が早すぎるなどの提案があります。しかし、私の質問は、最適化する時期についてです。すべてをキャッシュすることは私が求めていることではありませんが、キャッシュするときは誰の責任でしょうか？

4

2 に答える 2

2

一般に、最初にコードを機能させてから最適化し、プロファイリングが役立つと判断した最適化のみを行う必要があります。

于 2008-12-04T18:40:31.787 に答える
1

早すぎる最適化の罠に陥らないように、質問を逆にする必要があると思います。

呼び出しのたびにプロパティを再計算する必要がなくなり、代わりになんらかの形式のキャッシュを使用するポイントはいつだと思いますか?

値のキャッシュは最適化であるため、標準として行うべきではありません。この最適化を使用することが明らかに関連する場合もありますが、ほとんどの場合、適切な作業を行って値を取得し、プロファイリングして表示したら、それを最適化するようにして、毎回正しく機能するようにプロパティを実装する必要があります。その最適化が必要です。

キャッシュが良いアイデアである理由とそうでない理由: - 値が頻繁に変更される傾向がある場合はキャッシュしないでください - 変更されない場合はキャッシュし、変更しない責任がある場合はキャッシュしてください - 責任がない場合はキャッシュしないでください他の誰かの実装に依存しているときに価値を提供するため

値をキャッシュする理由と反対する理由は他にもたくさんありますが、キャッシュするときとキャッシュしないときの明確なルールはありません。それぞれのケースが異なります。

キャッシュする必要がある場合...

なんらかの形式のキャッシングが進むべき道であると判断したと仮定すると、そのキャッシングをどのように実行するかは、キャッシングする対象、その理由、および値がどのように提供されるかによって異なります。

たとえば、それがあなたの例のようにシングルトンオブジェクトまたはタイムスタンプである場合、単純な「設定されていますか?」値を一度設定する条件は有効なアプローチです (つまり、構築中にインスタンスを作成します)。ただし、データベースにヒットし、データベースがいつ変更されたかを通知する場合は、データベース値が変更されたことを示すたびにダーティになるダーティ フラグに基づいて値をキャッシュできます。もちろん、変更の通知がない場合は、呼び出しのたびに値を更新するか、取得間の最小待機時間を導入する必要があります (もちろん、値が常に正確であるとは限らないことを受け入れてください)。

どのような状況であっても、常に各アプローチの長所と短所を考慮し、値が参照されるシナリオを検討する必要があります。消費者は常に最新の値を必要としていますか、それともわずかな遅れに対処できますか? 価値の源泉をコントロールできていますか? ソースは変更の通知を提供しますか (または、そのような通知を提供するようにできますか)? ソースの信頼度は？アプローチに影響を与える要因は多数あります。

あなたが与えたシナリオを考えると...

ここでも、キャッシングが必要であると仮定します。

  1. データベースから取得された値ですが、選択された後も true のままです。
    データベースがその動作を保持することが保証されている場合は、最初に要求されたときに値をポーリングし、その後キャッシュすることができます。データベースの動作を保証できない場合は、より注意する必要があります。

  2. 組み込みのキャッシュに保存され、時々期限切れになる可能性がある値。
    「ときどき」がいつであるかを知っていると仮定して、キャッシュが時々ダーティとマークされ、キャッシュされた値を更新する必要があることを示すダーティ フラグ アプローチを使用します。そうでない場合は、定期的にキャッシュがダーティであることを示すタイマーを検討してください。

  3. 最初に計算する必要がある値は?
    その価値観で判断したいと思います。キャッシュが必要だと思われる場合でも、コンパイラによって既に最適化されている可能性があります。ただし、キャッシングが必要であると仮定すると、計算に時間がかかる場合は、構築中または などのインターフェイスを介して行う方がよい場合がありますISupportInitialize。

  4. 初期化に時間がかかる値。0.001秒、0.1秒、1秒、5秒???
    プロパティでこれを計算せず、値がいつ変化するかを示すイベントを実装します (これは、値が変化する可能性のある状況では便利な方法です)。初期化が完了すると、イベントが発生し、コンシューマーが値を取得できるようになります。また、これがプロパティに適していない可能性があることも考慮する必要があります。代わりに、コールバックを伴うメソッドなどの非同期アプローチを検討してください。

  5. 設定されている値ですが、他の何かが来て null に設定され、再入力する必要があることを示すフラグが設定される場合があります。
    これは、ポイント 2 で説明したダーティ フラグ アプローチの特殊なケースにすぎません。

于 2008-12-04T18:38:13.040 に答える