Performance

Performance issues in Linq

The ability to create Linq providers, broadcasting Linq to SQL queries and other formats is undoubtedly the greatest achievement of the ruling in the technology industry. But what is the charge for such achievements? The article Building a LINQ Provider briefly describes the process of creating a service provider like Linq To SQL. In addition, this article describes the path that passes Linq expression of the structure created by the compiler, before converting it into a SQL or another format.

In contrast to the normal code, the compiler does not produce on the basis of Linq expressions executable code, but instead includes a code for forming a special structure that describes the original Linq expression, the so-called Expression Tree. Further, this structure somehow passed Linq provider, which in turn parses it and converts to the desired format. All this is done at runtime. Ie calling a method with Linq query, we call the code that each time first creates Expression Tree, then passes it Linq provider, which in turn parses it using complex and resource-intensive algorithm.

You could cache the results of parsing, but apart from the fact that every time we are dealing with a newly created structure, and it can even be different. Differences can arise, firstly, because of the possibility to create such a structure by parts, such as in the following example:

var query =
    from e in db.Employee
    select e;

if (a > 0)
{
    query =
        from e in query
        where e.EmployeeID > id
        select e;
}

Second, the values ??of transmitted parameters, such as the parameter id in the example above, are incorporated directly into Expression Tree, making this structure depends on the values ??of the parameters.

As a result, we have to parse the Linq queries each time. It is clear that this approach is low speed of Linq queries we guarantee.

Turning to the test site ORMBattle.net, for example, to this chart, you can easily verify the validity of this assumption. Below is a table with the numbers from the chart that we will be interested.

Here, horizontal:

Vertical lists various Linq providers penultimate column - pure SQL, the latter - a unit of measure (RPS). The highest attainable standard of bold - is the SQL / Native Query.

Compared with the figures of the reference line LINQ Query you can see that some providers slowing client code using Linq queries may be dozens! times.

As BLToolkit struggles with the situation, provided that the parsing algorithm Expression Tree in BLToolkit no less complex and resource-intensive? We remember that the cache Expression Tree is impossible, but simple logic says that if you really want, you can.

Stratagem is as follows. For each request takes a cache BLToolkit already processed trees and compares them with the original. When comparing the trees are not captured fragments