Linq To Sql vs Entity Framework Performance
Solution 1
I think you should test it in a somewhat different way, in order to distinguish startup costs vs. execution costs. The Entity Framework, in particular, has substantial startup costs resulting from the need to compile database views (although you can do this in advance). Likewise, LINQ has a notion of a compiled query, which would be appropriate if executing a query multiple times.
For many applications, query execution costs will be more important than startup costs. For some, the opposite may be true. Since the performance characteristics of these are different, I think it's important to distinguish them. In particular, averaging startup costs into the average cost of a query executed repeatedly is misleading.
Solution 2
This looks to be a pretty measurement of performance between LINQ to SQL and Entity Framework.
http://toomanylayers.blogspot.com/2009/01/entity-framework-and-linq-to-sql.html
Solution 3
I did a couple of test asp.net pages trying to see which performs better. My test was:
Delete 10,000 records Insert 10,000 records Edit 10,000 records Databind the 10,000 records to a GridView and display on the page
I was expecting LinqToSQL to be faster but doing the above LinqToSQL takes nearly 2 minutes while LinqToEntities takes less than 20 seconds.
At least for this test it seems LinqToEntities is faster. My results seem to match yours as well.
I didn't try Inserting/Editing/Deleting/Displaying more than 1 table joined together though.
I'm interested in finding out more... or if my test isn't a valid type of test I'd be interested in seeing some real tests.
Comments
-
Non-maskable Interrupt almost 4 years
I have been searching for recent performance benchmarks that compare L2S and EF and couldnt find any that tested calling stored procedures using the released version of EF. So, I ran some of my own tests and found some interesting results.
Do these results look right? Should I be testing it in a different way?
One instance of the context, one call of the sproc: (dead link)
One instance of the context, multiple calls of the same sproc: (dead link)
Multiple instances of the context, multiple calls of the same sproc: (dead link)
-
Kevin Gauthier over 15 yearsNo, not necessarily. You can precompile the Entity Framework views, in which case you don't pay that cost when instantiating a context. Even for things which can't be precompiled, tracking these items separately clarifies the difference between a request which does one query & one which does 100.
-
undefined about 12 yearsI understand this is an old post but if you're still interested I've done some tests with EF which are available here(blog.staticvoid.co.nz/2012/03/entity-framework-comparative.html). i found L2S much slower at updates but i would love to know why (and if theres a way to improve it). L2S was much faster at Selects though
-
dtc about 12 yearsNice work. I'm far from an expert in databases and ORMs, but I like what your tests showed. I also recently read an article from the ADO.net team on EF5 improvements: blogs.msdn.com/b/adonet/archive/2012/02/14/…
-
undefined about 12 yearsthanks, yeah the EF team has been doing some pretty cool stuff lately around performance, interestingly most of it appears to have been done inside dot net 4.5 not the EF binaries which is cool as it gives a whole bunch of different techs a boost.