1

Linq to Sql with Sql Compact edition を使用して、WPF クライアント アプリを作成しています。データベースは比較的小さく (3MB)、読み取り専用です。

肝心なのは、パフォーマンスが期待したほど良くないということです。それを向上させるためのヒントと実用的な方法を探しています。

その他の事実: スキーマには、それらの間に広範な関係を持つ約 12 個のエンティティが含まれています。

アプリをプロファイリングすると、クエリが非常に高速に実行されていることがわかりましたが、c# エンティティの構築は最も時間がかかるプロセスです (最大 8 秒になる可能性があります)。ほとんどの場合、LoadWith を使用しており、DataContext はオブジェクト グラフをメモリ内に構築するしかありませんでした。

必要に応じて、追加情報を提供できます。

編集：

  1. 前述したように、データベースは読み取り専用であるため、DataContext は変更を追跡していません。
  2. 繰り返し発生するクエリで静的クエリを利用しています。問題は、アプリケーションの初期化時に、多くのオブジェクトをメモリにプリフェッチしてキャッシュとして提供する場合です。

ご協力いただきありがとうございます。

アリエル

4

2 に答える 2

1

エンティティはリレーションシップチェーンに割り当てられたメモリ（またはオブジェクトグラフのディープロード）を必要としないため、（積極的なロードではなく）遅延ロードを使用するとパフォーマンスが向上する（つまり、LoadWithの使用を避ける）ことができる場合があります。代わりに、オンデマンドで入力されます。

ただし、これをサポートするには、設計に集中する必要があります（そうしないと、SQL CEデータベースに対して実行されるSQLステートメントに関して、パフォーマンスのボトルネックが過度に「おしゃべり」になるように移動するだけです。

DataContextは、変更を追跡するときに肥大化（メモリ）を開始することもあります。データコンテキストの使用方法を検討する必要がある場合があります（たとえば、元のコンテキストが破棄されていれば、データコンテキストを新しいコンテキストにアタッチできます）。

于 2009-03-26T12:07:03.253 に答える
0

非常に簡単な解決策は、静的に宣言されたコンパイル済みの linq クエリを使用することです。もちろん、これはそれほど実用的ではありませんが、実行のためにクエリが呼び出されるたびに動的に作成されるのではなく、コンパイル時に一度だけ式ツリーを構築する必要があるため、パフォーマンスが向上します。

これは役立つかもしれません：

http://msmvps.com/blogs/omar/archive/2008/10/27/solving-common-problems-with-compiled-queries-in-linq-to-sql-for-high-demand-asp-net-ウェブサイト.aspx

于 2009-03-26T13:16:49.247 に答える