views:

153

answers:

4

Comparing the two data models in an asp.net MVC app, which provides better performance, LINQ 2 SQL or LINQ 2 Entities.

They don't always perform the same database operations when you use the same methods, or have the same LINQ methods for that matter....

+2  A: 

You should benchmark the specific query yourself. However, LINQ to Entities provides an extra abstraction layer in comparison to LINQ to SQL which is likely to impede performance a little.

Performance issues aside, if your application is expected to work with SQL Server backends only and you need a one to one mapping between entities and tables, LINQ to SQL is simpler to use.

Mehrdad Afshari
I agree that LINQ to SQL is simpler to use than LINQ to Entities, but sometimes with simplicity there is a lot of overhead attached (not that I'm saying that is the case here).
hminaya
+1  A: 

It depends very specifically on what you're doing. There is no single answer to this.

If you are willing to take the performance hit involved in using an ORM, both of them should be suitable.

My advice would is always go with an ORM for as much code as you can. If you have something that's running unacceptably slowly then make a stored procedure to do that specific query.

overstood
+1  A: 

This article seems to make some comprehensive comparisons:

http://toomanylayers.blogspot.com/2009/01/entity-framework-and-linq-to-sql.html

My general input though when I hear performance being mentioned is to choose a solution that best solves your problem until you discover that your problem is performance.

SevenCentral
+2  A: 

Maintainability over performance should be a goal at the outset of most projects even if performance is a requirement. Performance can be tuned later and with good design the ORM/data mapper can usually be swapped out later if it is necessary.

Don't bog yourself down with decisions like this early in a project. Sort with what is easier or what you already know. Then tune later.

Benchmark yourself for good results. Your environment is invariably always different to what the developer/manufacturer might use for comparisons.

cottsak