tags:

views:

715

answers:

3

Hey there I got a problem with my code, I compared three ways of implementing a query on a database

  1. Standard SQL Query (From * Select ...)
  2. LinQ Query
  3. Precompiled LinqQuery (CompiledQuery)

Now the result I got is that the Precompiled LingQuery is 5 times faster than the LinQ Query but much more interesting ist that the Standard SQL Query is approximately ten times fast than the Precompiled LinqQuery. The table that my Queries run against is one simple table with no associations to other tables.

The fact that makes the table interesting is that it consists of 5 columns which represent all together the primary key I mean. all columns together is unique so there is no row in the table that looks like the other. All columns are indexed.

Does anyone have an idea about what goes wrong with LinQ?

With kind regards

Sebastian

+1  A: 

How are you measuring? Are you using all of the query results, or just executing the query? (LINQ may well be fetching the results for you, for example.)

Does this happen the second time you execute the query too, or are you just measuring the time taken for the first execution?

Jon Skeet
Yes we are using all of the results we fetch, not just executing the query and it happens everytime and we measure the time for all queries not just for a single one
Xelluloid
+2  A: 

Have you had a look at the actual query that linq generates? Comparing those with your SQL query might give you some answers.

You can do this either using SQL Profiler or listening to the linq datacontext's Out property? You can do it like this in a console app:

DataContext ctx = new ...;
ctx.Log = Console.Out;
//Now execute the linq query, and the query will be output to the console.
Arjan Einbu
it is exactly the same query as I copied the query from the datacontext and used it for my query in SQL
Xelluloid
Strange... Is the query very, very complex (much processing to create the query from the query tree), but fast to execute on the server? That could maybe skew the results...
Arjan Einbu
yes I think the query is complex but I thought using the CompiledQuery would solve the problem, as the Expression tree is build when compiling not each time again I use the query?
Xelluloid
Have you measured the different parts of the process independently? Query generation separate from actual running time in the DB. Have you run all of the query through SQL Profiler?
Arjan Einbu
+2  A: 

Just make sure that your queries are not cached, that can skew the results.

CodeToGlory
we don't have multiple queries, each query is executed once. Do you mean that?
Xelluloid
My guess is that he means that if the query is run in Linq first then SQL Server will have to create an execution plan for the query. When you then run the same query through SQL Server the plan will already be cached and SQL won't have to spend the time recreating it. Run the following between tests: DBCC DROPCLEANBUFFERS and DBCC FREEPROCCACHE or make sure that you run each test once then just time the second runs.
Tom H.
if you query the same data rows over and over, it is cached into menory, making queries in the future faster since the data comes from ram and not hard drive
KM
I ran out of room in my first comment, but the DBCC DROPCLEANBUFFERS should take care of the data caching. The DBCC FREEPROCCACHE should take care of the execution plan caching (even for non-stored procedures - the name is slightly misleading)
Tom H.
Agree with Tom, before you run each test, run the above commands and share your results. Can you also post the query that is generated from LINQ?
CodeToGlory
Yes I'll try to speak with the person that produced the problem tomorrow^^ I think she talked about some solution last time but im not sure of :)
Xelluloid