17

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)

Vyrotek
  • 5,356
  • 5
  • 45
  • 70
  • What happens when you put your context creation lines in a using() block? Those longer-duration calls may be due to the system not having a connection in the pool...? – Dave Markle Nov 02 '08 at 16:39
  • 2
    You might want to also benchmark update, delete and insert performance. – DamienG Nov 02 '08 at 22:42
  • Does your data code usually look like this? Somehow it does not appear to look like real data access code... Testing for loops has nothing in common with what real data access patterns look like. – Jason Short Dec 04 '08 at 04:26

3 Answers3

9

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.

Craig Stuntz
  • 125,891
  • 12
  • 252
  • 273
  • But wouldnt these results reflect how things would work in an asp.net application? Since I cant really keep an instance either context 'alive' I have to make a new one on every request and call the stored procedure. – Vyrotek Nov 03 '08 at 18:39
  • 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. – Craig Stuntz Nov 03 '08 at 22:11
3

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

2

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.

dtc
  • 10,136
  • 16
  • 78
  • 104
  • 1
    I understand this is an old post but if you're still interested I've done some tests with EF which are available here(http://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 – undefined Apr 22 '12 at 06:18
  • 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: http://blogs.msdn.com/b/adonet/archive/2012/02/14/sneak-preview-entity-framework-5-0-performance-improvements.aspx – dtc Apr 24 '12 at 19:35
  • 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. – undefined Apr 25 '12 at 00:03