Since LINQ to SQL basically is a layer on top of ADO.NET it requires some translation. Does this mean that using ADO.NET directly is faster than LINQ? Or is the difference so small that it is irrelevant?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Since LINQ to SQL basically is a layer on top of ADO.NET it requires some translation. Does this mean that using ADO.NET directly is faster than LINQ? Or is the difference so small that it is irrelevant?
It does mean that ADO.NET is faster. It also gives you heaps of more freedom to optimize your SQL queries (well technically, you could use LINQ to SQL with stored procedures only, but you’d miss out on the whole point).
The fact is that if you really really really need to optimize for best performance, then nobody really recommends using an OR/M. There are heaps of considerations with OR/M:s, performance-wise. But a lot of sites do not really need to optimize that much for performance, in much the same way that we can afford programming in .NET rather than assembler, even though that is the same kind of overhead as compared to writing code in a lower level language.
The point of using LINQ to SQL or NHibernate, or really any other OR/M is that (as with the .NET analogy) it’ll give you a whole lot of convenience, and it’ll save you a lot of time developing, and make refactoring and other later changes a much simpler task.