Entity Framework dramatically faster in .NET 4.5
The Entity Framework is often shown lagging behind in performance comparisons with other ORM’s, especially when micro ORM’s are also included in the mix.
For example the Dapper benchmarks show the Entity Framework in a distant last place when testing SELECT mapping and serialization. These results have been charted on the excellent ServiceStack website.
However things have changed in .net 4.5 and the Entity Framework is no longer the slouch it once was.
The chart below shows the same benchmark, but this time including how the ORM’s fare when run on .NET 4.5.
The benchmark measures how long in milliseconds it takes to execute 500 SELECT statements against a DB and map the data returned to objects.
Now the Entity Framework competes with the other ORM’s on performance, and when compared with a fully featured ORM like nHibernate it compares very favourably (at least on this one metric).
It gets nowhere near the micro-ORM’s on performance, but feature rich ORM’s never will.
What is also interesting is that quite a few of the ORM’s also gain speed improvements in .NET 4.5
Is there a performance difference among the different flavors of EF (code first/db-first/etc.)? If there is a difference, which flavor was used for this benchmarking?
Dave Falkner
25 Oct 12 at 5:33 pm
[...] Performance improvements in EF5 Posted on October 25, 2012 by Roger Alsing Just saw this post today: http://www.outofmemory.co.uk/entity-framework-5-dramatically-faster-in-net-4-5/ [...]
Performance improvements in EF5 | Roger Alsing Weblog
25 Oct 12 at 5:47 pm
Dave, that is a splendid question. I hope someone with answers responds.
Clint Billedeaux
25 Oct 12 at 5:57 pm
One reason the new version is faster is that EF now automatically pseudo-compiles expressions and caches an intermediate version of the expression which saves a lot of time. If the test repeats the same expression, you’ll see a big difference (unless you were already using “EF Compiled” queries).
It would have been nice if EF cached the actual compiled delegate or at least made it available for implementers to cache and manage. The delegate is even faster and it would save programmers from having to declare lambdas to get compiled query speed.
Erik Johnson
25 Oct 12 at 6:03 pm
Do you know why this is? I wonder – is it specific optimisations within the .NET 4.5 runtime that EF can now use, or is it that EF has been significantly revamped? Would be really curious to know as the solution may help in other more general object mapping/instantiation code.
JB
25 Oct 12 at 6:12 pm
Dave/Clint – I think there was a small difference when I ran a benchmark to compare but it was minimal. I will follow up with another post, once I am sure I have got it correct.
Erik – Agree with you on this, it is not very convenient or pretty to have to compile all the queries. Maybe EF6 will improve things.
JB – I believe Erik has hit the nail on the head. The performance improvements are specific to EF5 and .net 4.5 in combination. You don’t get the improvements in the latest EF if you are still on .net 4.
andrew
25 Oct 12 at 8:18 pm
After some more thinking, if the worst performing ORM can perform 500 operations in 800ms, I’m going to base my ORM choice on other features.
Still, this looks like a fantastic improvement.
Dave Falkner
25 Oct 12 at 11:48 pm
I wish you would’ve tested BLToolkit as well. We get close to Dapper performance but still use LINQ (i.e. no magic strings). BLToolkit is about 3-4 times faster than Linq2Sql in the projects we worked with. And if you go through the effort of compiling BLToolkit LINQ queries you can get withing 10% of Dapper — pretty impressive imo. For a highly used page we went from a render time of 200ms to 60ms by simply swapping out Linq2Sql with BLToolkit.
Peter
26 Oct 12 at 2:40 am
Peter, I did test BLToolkit as well but had to remove quite a few scenarios to fit on the chart.
I will upload another chart shortly with BLToolkit on.
andrew
26 Oct 12 at 8:20 am
I’m maintaining the caching provider for Entity Framework, do you want to test the perfomances using it?
It’s on http://nuget.org/packages/EyeSoft.Data.EntityFramework.Caching. To enable the cache just write Database.DefaultConnectionFactory = new CachedContextConnectionFactory(); in the application start section. Is possible to use any distributed cache (Couchbase, AppFabric…) implementing the ICache interface and pass it to the CachedContextConnectionFactory.
Matteo Migliore
29 Oct 12 at 8:36 am
Yeah I will post another chart tomorrow with cached vs uncached.
andrew
31 Oct 12 at 9:20 am