, which are regarded as parameters. If the same initial request is in the cache, the original Expression Tree transferred him to extract the parameters, then the query is executed. To reduce the number of comparisons Point requests last move forward, but the main thing for each type of the value returned by the query is constructed separate cache. Thus the number of comparisons trees reduced to a minimum, and anonymous types, it is almost unique. The result you can see in the table - the usual BLToolkit Linq queries run faster even compiled Linq query of most providers.
CompiledQuery
To solve the above problem, many providers, including BLToolkit, offer so-called Compiled Query - Linq query compilation lambda, which can then be used without re-parsing. It looks as follows:
static Func
> _query =
CompiledQuery.Compile
>((db, n) => from e in db.Employee where e.EmployeeID > n orderby e.LastName, e.FirstName select e ); static void CompiledQueryTest() { using (var db = new NorthwindDB()) { var query = _query(db, 5); foreach (var item in query) { Console.WriteLine(item); } } }
|
All request is passed to the method Compile class CompileQuery, returns a compiled lambda, which can then be used like an ordinary function.
With this approach, the execution of queries on the client grows at times, but the board is clear - more cumbersome and non-obvious code.
Conclusion
At the end I want to thank everyone who took part in the discussion and testing Linq provider BLToolkit. Special thanks to the entire project , once again who became a testing ground for new ideas, and personally Andrei Koryavchenko for positive criticism, identified mistakes and a lot of interesting ideas.