I've come to know this concept of
AutoDetectChangesEnabled very recently. I understand that when fetching records from the database via Entity Framework with
AsNoTracking() used, then Entity Framework does not track any changes on those records and updating any property of the fetched record will fail in that case.
My question is if records are fetched in that manner, will it also cause disabling the automatic call to DetectChanges() or does that have to be done explicitly by setting:
Context.Configuration.AutoDetectChangesEnabled = false;
Also kindly let me know what impact (in terms of performance) does it have if both of the actions are performed while fetching the data strictly for read only purposes:
Context.Configuration.AutoDetectChangesEnabled = false; Context.Set<T>().AsNoTracking();
will it also cause disabling the automatic call to DetectChanges()
No it won't. But you must realize that
DetectChanges have nothing to do with each other (apart from being part of EF). Objects fetched with
AsNoTracking will never be change detected anyway, whether AutoDetectChanges is enabled or not. Besides,
AsNoTracking works on a
AutoDetectChangesEnabled on the context level. It would be bad to have a
DbSet method affect the whole context.
or that [setting
AutoDetectChangesEnabled] has to be done explicitly
Well, you probably just shouldn't disable AutoDetectChanges. If you do it you must know what you do.
what impact(in terms of performance) does it have if both of the action is performed
As said, they are not related. They can both improve performance in their own way.
AsNoTrackingis great if you want to fetch read-only data. It has no side effects (as in: its effect is clear)
AutoDetectChangesEnabled = false stops automatic calls of
DetectChanges (which can be numerous), but it has side effects you need to be aware of. From Lerman & Miller's book DbContext:
Working out when DetectChanges needs to be called isnâ€™t as trivial as it may appear. The Entity Framework team strongly recommends that you only swap to manually calling DetectChanges if you are experiencing performance issues. Itâ€™s also recommended to only opt out of automatic DetectChanges for poorly performing sections of code and to reenable it once the section in question has finished executing.
We have found that setting
AutoDetectChangesEnabled = false can have substantial (i.e. factor of 10) performance impacts.
Background: Our system is composed entirely of EF model objects that use change detecting proxies. That is, all of our DB fields and relational properties are declared as virtual. We also have a relatively deeply structured object model. That is object A contains a set of object B, which in turn contain a set of Object C, etc. We have observed that instantiating a non-trivial (> 100) number of these objects via a EF/LINQ query is expensive. For example, in one case instantiating 250 objects required about 2 seconds. We also observed that instantiating the same structure, but using anonymous objects instead required about 25 ms. Lastly, we observed that if we set
AutoDetectChangesEnabled = false, that we could use the query instantiating EF model objects and materialization again was about 25 ms.
So, at least for us, there were huge gains to be made by setting it false. We use a Unit Of Work pattern, and we explicitly indicate whether the Unit of Work is read-only or not. For a read-only unit of work, setting
AutoDetectChangesEnabled = false is perfectly safe, since there never will be any changes. In fact, we added this change to our system two years after our initial release (so there were many, many pre-existing unit of works in the code) and the change did not break anything at all, and significantly improved performance.
We also experimented with
AsNoTracking() and found that it gave us essentially no performance increase at all. As I understand it, a query with
AsNoTracking() means that the objects will not be placed into the identity map, and this will force EF to re-fetch the object from disk if it is referenced more than once within the context (e.g. in different queries). So there is some potential downside to