Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

DbContext is very slow when adding and deleting

When using DbContext in a database-first scenario I found out that adding and deleting entities is very slow compared to ObjectContext. If adding 2000 entities and saving the changes at the end, DbContext is 3 to 5 times slower than ObjectContext (btw.: I know that adding a large amount of entities would be better using SqlBulkCopy but that's not the point). If saving changes after each addition DbContext is still nearly two times slower. When it comes to deletion it even gets worse: When saving at the end of all entity removals, DbContext is around 18 times slower than ObjectContext.

I took my highly developed test application I use to compare database access technologies and a small console application to double check. Both showed bad results for adding and deleting entities using DbContext. Here are the results of the console application:

Inserting 2000 entities via DbContext saving changes at the end: 2164ms Inserting 2000 entities via ObjectContext saving changes at the end: 457ms Inserting 2000 entities via DbContext saving changes after each object addition: 8420ms Inserting 2000 entities via ObjectContext saving changes after each object adding: 4857ms Inserting 2000 entities via DbContext using a new DbContext for each object addition: 4018ms Deleting 2000 entities via DbContext saving changes at the end: 4794ms Deleting 2000 entities via ObjectContext saving changes at the end: 261ms Deleting 2000 entities via DbContext saving changes after each object deletion: 25536ms Deleting 2000 entities via ObjectContext saving changes after each object deletion: 2110ms 

I tried using EF 4.3 in VC 2010 and EF 5.0 Beta 2 in VS 11 with nearly same results. I used the T4 templates provided by the "EF 4.x POCO Entity Generator for C#", the "EF 4.x DbContext Generator for C#" and the "EF 5.x DbContext Generator for C#".

What could be wrong? According to the test results I would never use DbContext in an application that has to add or delete entities (what makes DbContext unfortunately unusable for me).

I put the console test applications on my web server: EF 4.3 DbContext Test, EF 5.0 DbContext Test

Any ideas/corrections are appreciated.

like image 470
Jürgen Bayer Avatar asked Apr 11 '12 09:04

Jürgen Bayer


People also ask

Should you use using with DbContext?

EF and EF Core DbContext types implement IDisposable . As such, best practice programming suggests that you should wrap them in a using() block (or new C# 8 using statement). Unfortunately, doing this, at least in web apps, is generally a bad idea.

When should you not use Efcore?

One of the biggest reasons not to use Entity Framework Core is that your application needs the fastest possible data access. Some applications do a lot of heavy data operations with very high-performance demands, but usually business applications don't have that high of a performance demand.

Should I dispose DbContext?

Don't dispose DbContext objects. Although the DbContext implements IDisposable , you shouldn't manually dispose it, nor should you wrap it in a using statement. DbContext manages its own lifetime; when your data access request is completed, DbContext will automatically close the database connection for you.

Which method is used to let the DbContext know an entity should be deleted?

DbContext. Remove Method (Microsoft.


1 Answers

Try to add this to your DbContext tests:

dbContext.Configuration.AutoDetectChangesEnabled = false;  // Now do all your changes  dbContext.ChangeTracker.DetectChanges(); dbContext.SaveChanges(); 

and try to run your tests again.

There was some architectural change in DbContext API which checks changes in entities every time you Add, Attach or Delete anything from the context. In ObjectContext API this detection run only when you triggered SaveChanges. It is better solution for most common scenarios but it requires special handling for mass data processing.

like image 66
Ladislav Mrnka Avatar answered Nov 10 '22 22:11

Ladislav Mrnka