468,257 Members | 1,419 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,257 developers. It's quick & easy.

Linq and performance

Hi guys
I have a one question, is Linq to Sql good in pefornace?
is better that traditional method? ismore than speed?? or is same?

Thanks..

Regards
Cesar
Jun 27 '08 #1
2 1398
That isn't a simple question...

There are obviously overheads with LINQ-to-SQL (as with any ORM): it
needs to parse expressions and translate to sql, and there are
obviously a few layers in this stack (although perhaps no more than a
standard business/DAL setup); the raw query at the database should be
*broadly* comparable.

Custom developer-written SQL might sometimes (if done well) be faster,
but equally it could be a lot worse - and consider that LINQ-to-SQL
will automatically adjust to the server (for instance, "paging" will
use CTE on SQL 2005, but a TOP / subquery / TOP on SQL 2000) - so it
might take advantage of things your own SQL doesn't.

Then we need to consider composability: with LINQ-to-SQL, if you build
a query, then add additional constraints ("where", etc) or other
operations ("orderby", etc) - then all of that goes down in the same
query. Likewise if you do a projection in the select (i.e. you only as
for a couple of columns) - then only those columns are SELECTed in the
SQL; this reduces network IO, and server disk IO (compared to running
a fixed query, and then ignoring various rows/columns in the results).

And then we also need to consider development effort: if it is going
to take you 10 minutes to drop a few tables onto the designer surface
and use them, compared to a day-or-so to do similar by hand, writing
lots of very, very similar code...

So I'm quite interested in LINQ-to-SQL and Entity Framework - but
really, you are going to have to do performance tests on your own
data, using realistic queries, to truly get an answer. But don't
forget - all those (small) overheads are on you app-servers, which you
easily scale "out", rather than the database server which you have to
scale "up".

I asked Mike Taulty this exact question the other day (talking about
Entity Framework). His answer was more or less the same as my own
conclusions (above).
Jun 27 '08 #2
Thank you Marc ...
Regards..
Cesar
"Marc Gravell" <ma**********@gmail.comescribió en el mensaje
news:ce**********************************@c58g2000 hsc.googlegroups.com...
That isn't a simple question...

There are obviously overheads with LINQ-to-SQL (as with any ORM): it
needs to parse expressions and translate to sql, and there are
obviously a few layers in this stack (although perhaps no more than a
standard business/DAL setup); the raw query at the database should be
*broadly* comparable.

Custom developer-written SQL might sometimes (if done well) be faster,
but equally it could be a lot worse - and consider that LINQ-to-SQL
will automatically adjust to the server (for instance, "paging" will
use CTE on SQL 2005, but a TOP / subquery / TOP on SQL 2000) - so it
might take advantage of things your own SQL doesn't.

Then we need to consider composability: with LINQ-to-SQL, if you build
a query, then add additional constraints ("where", etc) or other
operations ("orderby", etc) - then all of that goes down in the same
query. Likewise if you do a projection in the select (i.e. you only as
for a couple of columns) - then only those columns are SELECTed in the
SQL; this reduces network IO, and server disk IO (compared to running
a fixed query, and then ignoring various rows/columns in the results).

And then we also need to consider development effort: if it is going
to take you 10 minutes to drop a few tables onto the designer surface
and use them, compared to a day-or-so to do similar by hand, writing
lots of very, very similar code...

So I'm quite interested in LINQ-to-SQL and Entity Framework - but
really, you are going to have to do performance tests on your own
data, using realistic queries, to truly get an answer. But don't
forget - all those (small) overheads are on you app-servers, which you
easily scale "out", rather than the database server which you have to
scale "up".

I asked Mike Taulty this exact question the other day (talking about
Entity Framework). His answer was more or less the same as my own
conclusions (above).

Jun 27 '08 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

7 posts views Thread by Ronald S. Cook | last post: by
4 posts views Thread by =?Utf-8?B?V2lsc29uIEMuSy4gTmc=?= | last post: by
2 posts views Thread by SC | last post: by
7 posts views Thread by =?Utf-8?B?Q2hha3JhdmFydGh5?= | last post: by
22 posts views Thread by paululvinius | last post: by
reply views Thread by John Smith | last post: by
4 posts views Thread by Jacek Jurkowski | last post: by
5 posts views Thread by =?Utf-8?B?cmF1bGF2aQ==?= | last post: by
5 posts views Thread by ck1 | last post: by
reply views Thread by kermitthefrogpy | last post: by
reply views Thread by zattat | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.