2009-03-26 15 views
1

私はLinqをSql Compact EditionでSqlに使用してWPFクライアントアプリケーションを作成しています。 dbは比較的小さく(3MB)、読み取り専用です。パフォーマンスの向上Linq to Sql Compact Edition

ボトムラインは、パフォーマンスが私が望んでいたほど良くはありませんし、それを増やすためのヒントや実践的な方法を探しています。

多くの事実: スキーマには、それらの間に広範な関係がある約12のエンティティが含まれています。

アプリケーションをプロファイリングすると、クエリが非常に速く実行されていることがわかりましたが、C#エンティティを作成することは、最も時間がかかるプロセスです(最大8秒)。 私はLoadWithを使用していて、DataContextは選択肢がありませんが、メモリ内にオブジェクトグラフを作成するので、私は信じています。

必要に応じて追加情報を提供することができます。

EDIT:

  1. 私は、DBが読み取り専用のDataContextは、変更を追跡されないように説明したように。
  2. 私たちは再クエリを実行する際に静的クエリを利用しています。問題は、アプリケーションが初期化中で、多数のオブジェクトをメモリにプリフェッチしてキャッシュとして提供するときです。

ありがとうございました。

アリエル

答えて

1

さて、あなたは、エンティティが関係チェーンに割り当てられたメモリを必要としないので(むしろ積極的なロードより)遅延読み込みを使用することは(すなわちLoadWithを使用しないよう)の性能を高めるのを助けるかもしれないことを見つけるかもしれません(またはオブジェクトグラフの深い読み込み)、代わりに要求に応じて読み込まれます。

ただし、(これをサポートするために、デザインに集中する必要がありますそうでなければ、単にSQL CEデータベースに対して実行されたSQL文に関して過度に「おしゃべり」になるため、パフォーマンスのボトルネックを移動します。

DataContextは、変更を追跡するときに膨らみ始めます(メモリ)。データコンテキストの使い方(たとえば、元のコンテキストが破棄されている場合は新しいコンテキストに追加できます)を考慮する必要があります。

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-websites.aspx

+0

それはかなりの労力集中的な戦略だが、我々は非常にselectクエリでそれを追求について考えました。まだそれをテストする時間がなかった – RobS

関連する問題