views:

277

answers:

3

I have a very large Entity Framework implementation (100+ tables/entities). The first time SaveChanges is called when doing an update I am experiencing an 18 second wait time. Is this common for large entity framework models? I heard that partitioning the EF model into smaller chunks is a way to improve performance. I am wondering if this is the only way? Partitioning at this point seems like a whole lot of work.

  1. Should I partition the EF model?
  2. Should I use multiple data context instances or just a shared static one?
  3. What are the performance gotchyas that you have experienced with slowness on EF and in particular SaveChanges()?

Thanks!

A: 

No, this is not expected behavior. Our entity model is as large as yours and we don't see this. You need to profile your application to figure out what the problem actually is before you go off trying to solve it. I can't propose a solution for you without knowing what your profiling results are.

Craig Stuntz
Well, at least I know the problem is my solution :-)
markti
A: 

The place where we save most data in EF in a single operation, is several hundred rows spread over ca. 80 tables. This has a sub second response time.

It must be related to something else, things to check are:

  • Is there any CPU being used in these 18 seconds? By which process?
  • Could it be a network problem, waiting for a timeout?
  • Is it related to a constructor or jit compile?
Shiraz Bhaiji
1. Yes, on my core2 duo i am seeing 50% (i.e. one processor at 100%)2. DB is local, SQLExpress3. Doesn't appear to be...JIT counters don't seem to be spiking when performing login.
markti
@markti: can you uses the task manager to see which process is using 100% of cpu
Shiraz Bhaiji
Yes, it is the application itself.
markti
Do you have the possibility of debuging and checking that it is the SaveChanges() that is causing the spike?
Shiraz Bhaiji
I did. It is definitely the first time SaveChanges() is called where we actually write something (UPDATE or INSERT)
markti
@markti: Next thing to check is versions / installation, is there some old version installed, did you previously have a beta version installed?
Shiraz Bhaiji
A: 

I am seeing the same problem in a project of mine. The first call to SaveChanges takes about 12 seconds and full cpu time, the following calls don't.

The first polling of entities took about the same time before I used pregenerated Views. Now the 12 second first time polling delay is gone, but the first SaveChanges call still takes that long. Perhaps there is a way to pregenerate some code for SaveChanges too...

[Edit] I just wanted to mention that I managed to get rid of the delay at the first save, by changing the database structure. The Entity for which saving took so long was a big table with a lot of foreign key constraints to another table (don't ask). Removing the foreign key constraints did the trick. [/Edit]

mdk