As some of you may already know the Q2 release of RadGridView for WPF ships with a brand new “data engine” entirely based on LINQ. This means that all data operations including sorting, filtering, grouping, aggregating and paging will be pushed down to the IQueryProvider when RadGridView is bound to an IQueryable. For example if you are using LinqToSql, LinqToEntities or OpenAccess ORM all gird operations are executed on the SQL server using the magic of LINQ providers.
Staying on the cutting edge I decide to try out PLINQ (Parallel LINQ) and enable RadGridView to execute its data operations on all available CPU cores. PLINQ enables LINQ queries to be execute simultaneously on all cores using the new task parallel library that will be available in .NET 4. PLINQ is straight forward to use when you are constructing your queries in code, but this is not the case when you want to enable IQueryable over IParallelEnumerable. Unfortunately PLINQ did not provide built-in query provider, so I ended up implementing ParallelQuery class similar to EnumerableQuery for LINQ to Objects. This class internally rewrites the generated Expression Tree and proxies all calls to the ParallelEnumerable extension methods.
On the following screenshots you can see the CPU utilization before and after the PLINQ is used.
Before:
After:
As you can see when PLINQ is taking place both cores are fully utilized. You can imagine what will happen when you have 4 or 8 cores. And all of this for free with a simple one line change you have to do before binding the RadGridView.
[Update: If you are wondering why the CPU is utilized at its maximum and the occupied RAM is almost 3GB you should know that these screenshots are taken when the RadGridView is bound to collection with 15,000,000 items. Yes you heard me right this is 15 million.]
You can download the sample source here
P.S. Did I mention that this “data engine” will going to used in our ASP.NET MVC Grid.