Note: This is a follow up of What is the overhead of Entity Framework tracking? which asks about a rather old version of Entity Framework.
One of the team I am working with have used no tracking behavior at global level rather than at context or query level. This lead to strange code in the repositories since all injected context instances are not tracked: adding requires manual attaching, update has to explicit and some other explicit code related to navigation properties.
When asked about this, they invoked performance reasons, but failed to indicate a source.
My solution would be to use no tracking at context instance level. This would remove virtually all cumbersome code related to saving changes and the only issue would be when the programmer forgets to set no tracking for the instance. My assumption is that would not be such a big deal under normal circumstances (trees of several hundreds models).
This article suggests a big difference (both memory and CPU) between systematic usage of no tracking and everything tracked, but it is not clear if this only related to this (the difference seems much bigger than just the cloned data required for tracking).
Question: What is the overhead of tracking in Entity Framework 3.1?
What is the overhead of tracking in Entity Framework 3.1?
It's exactly the same as attaching every entity you query to the change tracker manually.
You can also opt-in to tracking for a single query with .AsTracking().