Latest Dapper VS Entity Framework 6 performance considerations

Question

There are a few performance comparisons between Dapper (which seems to be the fastest, most popular "micro ORM tool"). Now it's September 2014 and we have Entity Framework 6 (not 5, or 4) and Dapper is still around.

We will begin developing a huge database n-tier application (database has 700 tables). And some of the queries that need to be run are quite time-sensitive.

1. Does anyone have any updates on performance regarding EF 6.1.x? This concerns general queries made within a DbContext.
2. I suppose I cannot use nicely formatted LINQ queries with Dapper. Do you have experience with that? Is it worth losing LINQ for the additional speed?
3. IS Dapper still under active, constant development? GitHub tells me yes, but as with Subsonic, that can change rather quickly.
4. Is it feasable/doable to mix Dapper and EF? Dapper when we need the speed, otherwise EF.

Thank you!

Answer 1

1. Does anyone have any updates on performance regarding EF 6.1.x? This concerns general queries made within a DbContext?

Ans: I don't have specific numbers, but I have updated the performance rig to EF6; I can't remember the outcome exactly, but: EF6 is a lot faster than EF-old, but dapper is still significantly faster in many scenarios (and about the same for the edge-cases)

2. I suppose I cannot use nicely formatted LINQ queries with Dapper. Do you have experience with that? Is it worth losing LINQ for the additional speed?

Ans: That is subjective; for us: yes, absolutely worth it - but we care lots about speed. Parsing expression trees has impact, and generated SQL is very rarely in the same league as handcrafted SQL by a decent dev

3. IS Dapper still under active, constant development? GitHub tells me yes, but as with Subsonic, that can change rather quickly?

Ans: Absolutely; I think I've deployed about 4 versions this month...

4. Is it feasable/doable to mix Dapper and EF? Dapper when we need the speed, otherwise EF?

Ans: Yes, you can do that; that is how we started with dapper - we used that to replace LINQ to SQL code that was causing performance problems; over time, that had grown, and now we have very little LINQ to SQL code remaining (but still some)