ppanyukov/entityframeworkbenchmarks

Quick ASP.NET 5 Web Api project to compare Entity Framework 7 (beta 4) performance against dapper.net and raw ADO.NET.

entityframeworkbenchmarks's Issues

Disable Lazy Loading

By default EF uses lazy loading

Tests bind EF in a different lifecycle to the other frameworks

I'm always a bit skeptical when I see differences of more than a factor 2 when looking at benchmarks. In reality most frameworks are pretty close in performance with the exception of edge cases around specific functionality.

I think that your specific 3-6x slower figure is coming from the way you manage your lifecycle.

https://github.com/ppanyukov/EntityFrameworkBenchmarks/blob/master/src/EntityFrameworkBenchmarks/Startup.cs#L22-L29

You are using a completely different type of lifecycle (transient vs singleton) for EF and dapper. This means (amongst other things) you are creating a new connection when querying EF and reusing the connection with dapper.

Use AsNoTracking for EF

EF tracks query results by default, which incurs additional overhead because we need to take snapshots of entities as they are materialized.

Using AsNoTracking would be semantically closer to the Dapper and raw ADO examples.

Re-test with latest beta of EF7 (or RTM)

The benchmarks are currently for Beta-4 which is quite old. It would be good to rerun with the later beta or the RTM, whatever comes first.

Discussion: Where we are at with perf in EF7

Hey,

Feel free to close this one out, I just wanted to follow up with some comments on our approach to performance in EF7. Below are some thoughts from a discussion in our repo around perf.

We have benchmarks for the basic scenarios in EF7 and we have some scenarios that are greatly improved over EF6 and others that are still quite slow. We have these on a list to address but we haven't optimized the code paths yet because the code paths are still changing quite rapidly. If we'd optimized things before now then we'd likely have wasted a lot of time as things have changed so much and we'd end up hitting different bottlenecks.

The code base is starting to churn less now, so we are starting to look at these. We still have plenty of time to get things tidied up before we need to RTM. ASP.NET 5 is the main driving force behind the dates for our initial RTM of EF7 and they have announced that they will still be pre-release when Visual Studio 2015 reaches RTM (so EF7 still has a while before it reaches RTM). I can't comment on specific dates since they are up to the Visual Studio and ASP.NET 5 teams to make public.

BTW we are also working on some things now that will eventually end up with the results of our automated performance runs being public.

~Rowan