Entity Framework V4: "Code Only" performance considerations

Question

I'm about to start working on a new project and am wondering if "Code Only" is the right way to go. We're also considering the other model-first approach through the designer, but would rather design my domain models outside of the EF designer.

Our domain will likely contain 100+ entities. I've read that a huge number of entities can somewhat slow down EF (ie: Creating the context and first call to SaveChanges).

Since there's no EDMX file to store the metadata, is this approach likely to be slower? I've searched the web but haven't been able to find any information on this.

I know this is still only in CTP and missing lots of functionality, but I'm just looking for input/guidance at this point.

Answer 1

As .NET 4, including EF4 is Beta 1 currently you are not going to get any useful general answer. For your specific case why not test.

Create an entity model with one entity and run some performance tests. Then expand the model to have more entities and re-run the test. If there is a performance impact of the number of entities in the model you should see a performance difference.

Remember to discount load effects, unless you are only interested in applications that start up, perform a single operation and then shutdown.

Answer 2

Internally Code-Only caches metadata so, once the first context has been created you should see very little difference in performance between Code-Only and the EDMX approach.

You are right that a large number of entities can slow down EF.

Pregenerating Views is often recommended to help performance with large models. But that feature relies on having an EDMX file, so not surprisingly it doesn't work with Code-Only.

However if you find you need to pre-compile views you could always to use the ToEdmx() feature of CodeOnly to move from the CodeOnly world to the standard EDMX world. And of course once in the EDMX world you can pre-compile your views.

However this is not necessarily the approach I would take.

I think a context with 100 or more IQueryable properties is less than ideal from a useability perspective anyway.

So rather than move away from Code-Only to pre-gen views, I'd probably leverage Code-Only's ability to make it easy to create smaller targeted subdomains, to minimize the effective size of the model for the part of the App you are working on.

The result would be a number of fast, easy to use ObjectContexts, targeted for the current set of tasks.

Which IMHO is much more desirable.

Hope this helps

Alex

Answer 3

• Performance Considerations for Entity Framework Applications
• Exploring the Performance of the ADO.NET Entity Framework - Part 1
• Exploring the Performance of the ADO.NET Entity Framework – Part 2