DbContext ChangeTracking kills performance?

Question

I am in the process of upgrading an application from EF1 to EF4.1 I created a DbContext and a set of POCOs using the "ADO.NET DbContext Generator" templates.

When I query the generated DbContext the database part of the query takes 4ms to execute (validated with EF Profiler). And then it takes the context about 40 seconds (in words: FORTY!) to do whatever it does before it returns the result to the application.

EF1 handles the same query in less than 2 seconds.

Turning off AutoDetectChanges, LazyLoading and ProxyGeneration wins me 2-3 seconds.

When I use the AsNoTracking() extension method I am able to reduce the total execution time to about 3 seconds.

That indicates that ChangeTracking is the culprit.

But ChangeTracking is what I need. I must be able to eventually persist all changes without having to handpick which entities were modified.

Any ideas how I could solve that performance issue?

Answer 1

Is the technique at the end of this documentation useful? Alternatively, I've avoided many of the performance pitfalls using a fluent interface to declaratively state which entities in a given transaction for sure won't change vs. might change (immutable vs. immutable). For example, if the entities I am saving are aggregate roots in which the root or its entities refer to "refdata" items, then this heuristic prevents many writes because the immutable items don't need to be tracked. The mutable items all get written without check (a weakness... One which may or may not be acceptable).

I'm using this with a generic repository pattern precisely because I don't want to track changes or implement a specific strategy for each case. If that's not enough, perhaps rolling your own change tracking outside of the context and adding entities in as needed will work.

Answer 2

Without seeing the query, I can't say for sure what the problem might be. Could this be related?

Why does the Contains() operator degrade Entity Framework's performance so dramatically?

Depending on the LINQ operators being used, it appears that EF has a tough time converting some queries to SQL. Maybe you're running up against a similar situation here.