Entity Framework 4.1 vs Enterprise Data Application Block Maximum Performance

Question

Problem scope: I want to use EF4.1 without any trade offs to the speed and reliability of the Enterprise Library Data Access Block that I know and trust.

Thanks to lots of Stackoverflow links and blogs about EF performance tuning I'm posting this way , among many, to use EF4.1 that matches the performance of ADO/ Enterprise Lib Data Access Block (SqlDataReader).

The Project: 1. No linq to Entities/ dynamic sql. I love linq, I just try to use it against objects mostly. 2. 100% stored procedures and no tracking, no merge, and most importantly, never call .SaveChanges(). I just call the insert/ update/ delete proc DbContext.StoredProcName(params). At this point we have eliminated several of the rapid dev elements of EF but the way it auto creates a complex type for your stored proc is enough for me.

The GetString and similar methods are an AbstractMapper that just goes through the expected types and casts the datareader into the type.

So this is the mark to beat as far as I'm concerned. It would be hard to adopt something I know to be slower.

That is SLOWER!!! A lot slower!

That is more like it!! Performance Pie Based on my results that performance pie should increase the tracking overhead by a lot more than 1% I tried pre compiling the views and nothing got as big of a boost as no tracking! Why?? Maybe somebody can chime in on that.

So, this one is not really fair to compare to Enterprise Lib, but I'm making one untimed call to the database to load the the meta data that I understand is loaded once per IIS app pool. Essentially once in the life of your app.

I'm using EF this way with auto stored procedure generation and I used Linq to Edmx to auto import all these edmx function nodes to map up to the entities. Then I auto gen a repository for each entity and an engine.

Since I never call SaveChanges, I don't bother taking the time to map to stored procs in the designer. It takes too long and it is way to easy to break it and not know it. So I just call the procs from the context.

Before I actually implement this in my new mission critical medical equipment delivery web application I would appreciate any observations and critiques.

Thanks!

Answer 1

Just a few remarks:

Performance Pie Based on my results that performance pie should increase the tracking overhead by a lot more than 1% I tried pre compiling the views and nothing got as big of a boost as no tracking! Why??

The blog post is from 2008 and therefore based on EF Version 1 and on EntityObject derived entities. With EF 4.1 you are using POCOs. Change tracking behaves very differently with POCOs. Especially when a POCO object is loaded from the database into the object context Entity Framework creates a snapshot of the original property values and stores is in the context. Change tracking relies on comparison between current entity values and original snapshop values. Creating this snapshot is apparently expensive in terms of performance and memory consumption as well. My observations are that it costs at least 50 percent (query time without change tracking is the half of the query time with change tracking). You seem to have measured an even bigger impact.

The Project: 1. No linq to Entities/ dynamic sql. I love linq, I just try to use it against objects mostly. 2. 100% stored procedures and no tracking, no merge, and most importantly, never call .SaveChanges(). I just call the insert/ update/ delete proc DbContext.StoredProcName(params). At this point we have eliminated several of the rapid dev elements of EF but the way it auto creates a complex type for your stored proc is enough for me.

For me this looks like you are ignoring essentially some of the main features why Entity Framework exists and it is questionable why you want to use EF for your purpose at all. If your main goal is to have a tool which helps to materialize query results into complex objects you could take a look at Dapper which focusses on this task with high performance in mind. (Dapper is the underlying ORM used here at Stackoverflow.)

A few days ago here was a question with great answers about EF performance. It has been migrated to "Programmers" now:

https://softwareengineering.stackexchange.com/questions/117357/is-entity-framework-suitable-for-high-traffic-websites