LINQ query versus compiled LINQ query

Rico Mariani changed his position a few months ago but he still manages to provide his Performance Quizzes from time to time. Today he explains the difference between LINQ queries and compiled LINQ queries. It's obvious that one should cache as much as possible because in most cases is better to pay a high price once then a slightly reduced one many times. But the interesting part of the post is the way how Microsoft came up with their current implementation of compiled LINQ queries. Nearly every good performance solution is a matter of realizing that being very generic doesn't pay off. Crazy about performance topics? Go and solve Rico latest quiz. Once you are done check if you are right.

LINQ and its diverse incarnations

LINQ as a concept is highly extensible and every now and then a new LINQ to WhatEverYouWant gets announced. Just a few examples to show how fast people are adopting this technology: LINQ to LLBLGEN, LINQ to NHibernate, LINQ to Filckr, LINQ to Amazon, etc. Within a few days I've come across 3 more projects:

• SyncLinq - it returns collections that implement INotifyCollectionChanged which lets you track changes
• PLinq - it lets you specify that a given LINQ statement should be executed concurrently and it's up to the runtime to decide how many CPUs will be used
• DryadLinq - the same as PLinq, just replace CPU with PC, basically it lets you specify that your query should be executed on many machines

It looks like LINQ is a powerful platform itself. It has enabled people to create many different levels of abstractions that are based on nearly the same syntax. It's amazing because if I want to stay close to bare metal I can go for Linq, if I want to get some additional services like change tracking I can go for SyncLinq. If I want to take advantage of my N > 1 cores without messing with threads I can go for PLinq and finally if I have N > 1 machines that nobody uses :) I would definitely go for DryadLinq. Diversity in its best shape.