Table of contents
Introduction and goal
LINQ has been criticized by many early adopters for its performance issues. Well, if you are just going to drag and drop using a DBML code generator, I am sure you will land up in a mess. Try doing this, make a simple LINQ to SQL project using DBML and see your SQL profiler. I am sure you will never like to touch a DBML code generator again.
In this article, we will first look into how LINQ queries are executed, and then we will touch base on how compiled LINQ queries can help us improve our application performance at least 5 times. My numbers can be 10% up and down as I had come to that figure using my environmental situations.
Still new to LINQ? Below are some real quick starters
This article requires some pre-requisites, in case you are new to LINQ I would suggest you to go through the below links.
Deep dive into how LINQ queries work
Before we get into how we can improve LINQ query performance, let’s first try to understand the various steps involved in a LINQ query execution. All LINQ queries are first converted to SQL statements. This conversion also involves checking of LINQ query syntaxes and translating the queries to SQL.
Below is a simple LINQ query which selects data from a customer table. This LINQ query is then transformed into the necessary SQL statements by the LINQ engine.
The checking of syntaxes and generating the SQL query accordingly is a bit of a tedious job. This task is performed every time we fire a LINQ query. So if we can cache the LINQ query plan, we can execute much faster.
LINQ has provided something called as compiled LINQ queries. In compiled LINQ queries, the plan is cached in a static class. As we all know, a static class is a global cache. So LINQ uses the query plan from the static class object rather than building and preparing the query plan from scratch.
Figure: LINQ query caching
In all, there are four steps which need to be performed right from the time LINQ queries are built till they are fired. By using compiled LINQ queries, the four steps are reduced to two.
Figure: Query plan bypasses many steps
Steps involved in writing compiled LINQ queries
The first thing to do is to import the Data.Linq namespace.
Import namespace using System.Data.Linq;
The syntax to write compiled queries is a bit cryptic and many developers do not like the way the syntax is. So let us break the syntax into small pieces and then we will try to see how the complete syntax looks like. To execute a compiled function, we need to write a function to pointer. This function should be static so that the LINQ engine can use the query plan stored in the static class objects. Below is how we define the function. It starts with public static stating that this function is static. Then we use the Func keyword to define the input parameters and output parameters. Below is how the parameter sequence needs to be defined:
- The first parameter should be a data context. So we have defined the data type as
DataContext. - Followed by one or many input parameters. Currently we have only one, i.e., customer code, so we have defined the second parameter data type as
string. - Once we are done with all input parameters, we need to define the data type of the output. Currently we have defined the output data type as
IQueryable.
We have named this delegate function getCustomers.
public static Func<DataContext, string, IQueryable<clsCustomerEntity>> getCustomers
We need to call the method Compiled of the static class CompiledQuery with the DataContext object and necessarily define input parameters followed by the LINQ query. For the below snippet, we have not specified the LINQ query to minimize complications.
CompiledQuery.Compile((DataContext db, string strCustCode)=> Your LINQ Query );
Uniting the above two code snippets, below is how the complete code snippet looks like:
public static Func<DataContext, string, IQueryable<clsCustomerEntity>>
getCustomers= CompiledQuery.Compile((DataContext db, string strCustCode)=> Your LINQ Query );
We then need to wrap this static function in a static class. We have taken the above defined function and wrapped that function in a static class clsCompiledQuery.
public static class clsCompiledQuery
{
public static Func<DataContext, string, IQueryable<clsCustomerEntity>>
getCustomers = CompiledQuery.Compile((DataContext db, string strCustCode)
=> from objCustomer in db.GetTable<clsCustomerEntity>()
where objCustomer.CustomerCode == strCustCode
select objCustomer);
}
Consuming the compiled query is pretty simple; we just call the static function. Currently, this function returns the data type IEnumerable. We have to define an IEnumerable customer entity which will be flourished through the getCustomers delegate function. We can loop through the customer entity using the clsCustomerEntity class.
IQueryable<clsCustomerEntity> objCustomers =
clsCompiledQuery.getCustomers(objContext, txtCustomerCode.Text);
foreach (clsCustomerEntity objCustomer in objCustomers)
{
Response.Write(objCustomer.CustomerName + "<br>");
}
Performance comparison
Out of curiosity, we thought to do some kind of comparison to see how much the performance difference is. We took a simple customer table with 3000 records in it and we ran a simple query on the customer code. We have attached the sample source with the article. Below is a simple screenshot:
What we have done in this project is we have executed a LINQ SQL without query compilation and with query compilation. We have recorded the time using the System.Diagnostic.StopWatch class. Here’s how the performance recording has taken place. We start the stop watch, run the LINQ SQL without compile, and then we stop the watch and record the timings. The same way we have recorded the performance LINQ query with compilation.
We create the data context object and start the stop watch.
System.Diagnostics.Stopwatch objStopWatch = new System.Diagnostics.Stopwatch();
DataContext objContext = new DataContext(strConnectionString);
objStopWatch.Start();
We run the LINQ query without compilation. After execution, stop the watch and record the time differences.
var MyQuery = from objCustomer in objContext.GetTable<clsCustomerEntity>()
where objCustomer.CustomerCode == txtCustomerCode.Text
select objCustomer;
foreach (clsCustomerEntity objCustomer in MyQuery)
{
Response.Write(objCustomer.CustomerName + "<br>");
}
objStopWatch.Stop();
Response.Write("The time taken to execute query without compilation is : " +
objStopWatch.ElapsedMilliseconds.ToString() + " MillionSeconds<br>");
objStopWatch.Reset();
Now we start the stop watch again, run the LINQ query with compilation, and record the time taken.
objStopWatch.Start();
IQueryable<clsCustomerEntity> objCustomers =
clsCompiledQuery.getCustomers(objContext, txtCustomerCode.Text);
foreach (clsCustomerEntity objCustomer in objCustomers)
{
Response.Write(objCustomer.CustomerName + "<br>");
}
objStopWatch.Stop();
Response.Write("The time taken to execute query with compilation is : " +
objStopWatch.ElapsedMilliseconds.ToString() + " MillionSeconds");
Analyzing the results
When we measure performance, we need to see the time of execution the first time as well as subsequent times. At least 8 recordings are needed so that any kind of .NET runtime performance is averaged out. There are two important points we can conclude from the experiment:
- We need to excuse the first reading as there can be a lot of .NET Dramework object initialization. It can lead to a lot of wrong conclusions as there is a lot of noise associated with the first run.
- The subsequent readings have the real meat difference. The average difference between them is 5 times. In other words, a LINQ query executed using no compilation is 5 ms slower than compiled LINQ queries.
| | No Compilation | Milliseconds Query Compilation |
| First time | 4 | 124 |
| Second time | 9 | 2 |
| Third time | 7 | 2 |
| Fourth time | 7 | 1 |
| Fifth time | 6 | 2 |
| Sixth time | 7 | 2 |
| Seventh time | 6 | 2 |
| Eight time | 6 | 2 |
Below is a graphical representation and you can see how compiled queries have better performance than non-compiled ones.
Hardware and software configuration used for test conduction
- The web application and database application where on different boxes.
- Web application was running on Windows XP using a simple personal web server provided by VS 2008 (sorry for that guys, but did not have other options at that moment). Web application PC hardware configuration was 2 GB RAM, P4, 80 GB hard disk.
- Database was SQL Server 2005 on a Windows 2003 Server with 2 GB RAM, P4, 80 GB hard disk.
For further reading do watch the below interview preparation videos and step by step video series.
