Linq To Sql vs Entity Framework Performance

25,313

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.

Share:
25,313
Non-maskable Interrupt
Author by

Non-maskable Interrupt

http://www.vyrotek.com

Updated on July 09, 2020

Comments

  • Non-maskable Interrupt
    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
    Kevin Gauthier over 15 years
    No, 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
    undefined about 12 years
    I 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-comparat‌​ive.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
    dtc about 12 years
    Nice 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
    undefined about 12 years
    thanks, 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.