LINQ To SQL

[Jacek Jurkowski]

Why is it so slow? I really like
that queries but using DataReader
i have done my task's much more faster
than ising LINQ...

[Marc Gravell]

Define slow? It depends on what your queries are, and whether you have
caused it to do multiple round-trips (for sub-data) rather than
loading data early, and whether you've filtered things at the right
point [in the composable query, rather than downstream]. In general,
the (fixed) network IO vastly outweighs any client implementation
details like LINQ, but you might need to be more specific to get a
sensible answer...

Marc

[=?Utf-8?B?UGFua2Fq?=]

LINQ does 10-15 other steps before generating the actual query, which makes
LINQ slow. But it might be good if you have a multi processor system, because
LINQ is degined to take multi processor to make the things fast.

regards,
Pankaj
http:\\a2zdotnet.com

"Jacek Jurkowski" wrote:

Why is it so slow? I really like
that queries but using DataReader
i have done my task's much more faster
than ising LINQ...

[Marc Gravell]

LINQ does 10-15 other steps before generating the actual query, which makes

LINQ slow.

Care to be more specific? What steps are you referring to? Note that
you can use a few tricks to speed things up; for example (I haven't
used it myself) compiled queries:
http://msdn.microsoft.com/en-us/libr...qtosql_topic14

You might also wish to disable object tracking if you don't need it,
and write your query (or use load options) such that any sub-data you
need is retrieved in the first query rather than lazily. Again, you
really need to give some indication of what you are seeing as "slow"
to disuss them sensibly. You say there are 10-15 other steps: which of
them, exactly, is offending you?

But it might be good if you have a multi processor system, because
LINQ is degined to take multi processor to make the things fast.

I'm not aware of LINQ-to-SQL doing anything so exotic; you may be
thinking of "Parallel Extensions"

Marc

[Jeroen Mostert]

Jacek Jurkowski wrote:

Why is it so slow? I really like
that queries but using DataReader
i have done my task's much more faster
than ising LINQ...

Read this series and you might start thinking otherwise:
http://blogs.msdn.com/ricom/archive/...ce-part-1.aspx

There's a cost, obviously, and you will never get faster than using a raw
DataReader, but the performance overhead can be brought down considerably.
Did you use CompiledQuery and time multiple executions?

If the problem is not in the reflection and code generation of LINQ, you may
want to have a look at what SQL output you're actually generating. It may
not be optimal for a variety of reasons. LINQ abstracts considerably over
queries so you don't have to, but it's not perfect, and it can especially
break down if you mix in other constructs with LINQ to Objects. You can use
a tool like LINQPad (http://www.linqpad.net/) to see what your LINQ queries
are actually compiling to.

Finally, the ease of use of LINQ mean that it'll help you speed up
development even if you don't use LINQ to generate the actual queries. LINQ
works just as well with stored procedures, so if you have a particularly
tough query that needs careful optimization, you can stick it in a sproc and
use a few lines of declarative code (or a drag and drop from the Server
Explorer) to get a strongly-typed method for it.

--
J.