EntityFramework の DbContext は、実行する操作 (追加、削除、変更、クエリ) が増えるほど遅くなるようです。いくつかの操作の後に定期的に SaveChanges() を呼び出しても、その問題は解決されません。唯一の回避策は、コンテキストを破棄して再生成することです。
アイデアを伝えるために: 1 つの DbContext を使用するプロセスには約 4 時間かかりますが、回避策を含むコードは約 45 分しかかからないため、非常に重要です。私が知らない理由やスイッチはありますか？
EF5 のパフォーマンスに関する考慮事項に関する便利なリンクを次に示します。
変更追跡プロキシを使用していますか? そうでない場合は、速度を上げることができる場合があります。リンクから：
POCO エンティティに変更追跡プロキシがない場合、変更は、エンティティの内容を以前に保存された状態のコピーと比較することによって検出されます。この詳細な比較は、コンテキスト内に多くのエンティティがある場合、またはエンティティに非常に大量のプロパティがある場合、最後の比較が行われてからプロパティが変更されていなくても、時間のかかるプロセスになります。
それ以外の場合DbContextConfiguration.AutoDetectChangesEnabled = falseは、コメントやリンクで提案されているように設定できます。DetectChanges()通常は自動的に呼び出される集中的な DbSet/DbContext メソッド呼び出しを行った後でも、明示的に呼び出すことができます。
また、コンテキスト内のエンティティの数を減らすことはできますか? ObjectStateManager で追跡する必要のないエンティティがある場合は、おそらく AsNoTracking() クエリを使用します。
EntityFramework の DbContext は、実行する操作 (追加、削除、変更、クエリ) が増えるほど遅くなるようです。
絶対にそうです-あなたのDbContext（およびそれが基づいているObjectContext）は、これまでに触れ、ロード、更新、保存したすべてのエンティティを保存しました。
MSDN ブログ投稿からの簡単な抜粋:
通常、ObjectContext を使用すればするほど、サイズが大きくなります。これは、これまでに知っているすべてのエンティティへの参照を保持しているためです。基本的には、クエリ、追加、または添付したものは何でもです。したがって、同じ ObjectContext を無期限に共有することを再検討する必要があります。
このプロセスには約 4 時間かかるとおっしゃっていたので、何千ものエンティティが変更されていると思います。[変更を保存] はオブジェクト グラフをダンプしません。追跡するためにどんどん作成しているだけです。変更を加えるたびに、グラフをトラバースする必要があるため、グラフが大きいほど時間がかかります。
あなたの回避策は本当に悪いコードですか? プロセスを分割して、各セクションが作成し、共有するのではなく、独自の DbContext を破棄する方法はありますか?