Understanding how the C# compiler deals with chaining linq methods

I'm trying to wrap my head around what the C# compiler does when I'm chaining linq methods, particularly when chaining the same method multiple times.

Simple example: Let's say I'm trying to filter a sequence of ints based on two conditions.

The most obvious thing to do开发者_如何学编程 is something like this:

IEnumerable<int> Method1(IEnumerable<int> input)
{
    return input.Where(i => i % 3 == 0 && i % 5 == 0);
}

But we could also chain the where methods, with a single condition in each:

IEnumerable<int> Method2(IEnumerable<int> input)
{
    return input.Where(i => i % 3 == 0).Where(i => i % 5 == 0);
}

I had a look at the IL in Reflector; it is obviously different for the two methods, but analysing it further is beyond my knowledge at the moment :)

I would like to find out:

a) what the compiler does differently in each instance, and why.

b) are there any performance implications (not trying to micro-optimize; just curious!)

The answer to (a) is short, but I'll go into more detail below:

The compiler doesn't actually do the chaining - it happens at runtime, through the normal organization of the objects! There's far less magic here than what might appear at first glance - Jon Skeet recently completed the "Where clause" step in his blog series, Re-implementing LINQ to Objects. I'd recommend reading through that.

In very short terms, what happens is this: each time you call the Where extension method, it returns a new WhereEnumerable object that has two things - a reference to the previous IEnumerable (the one you called Where on), and the lambda you provided.

When you start iterating over this WhereEnumerable (for example, in a foreach later down in your code), internally it simply begins iterating on the IEnumerable that it has referenced.

"This foreach just asked me for the next element in my sequence, so I'm turning around and asking you for the next element in your sequence".

That goes all the way down the chain until we hit the origin, which is actually some kind of array or storage of real elements. As each Enumerable then says "OK, here's my element" passing it back up the chain, it also applies its own custom logic. For a Where, it applies the lambda to see if the element passes the criteria. If so, it allows it to continue on to the next caller. If it fails, it stops at that point, turns back to its referenced Enumerable, and asks for the next element.

This keeps happening until everyone's MoveNext returns false, which means the enumeration is complete and there are no more elements.

To answer (b), there's always a difference, but here it's far too trivial to bother with. Don't worry about it :)

1. The first will use one iterator, the second will use two. That is, the first sets up a pipeline with one stage, the second will involve two stages.

2. Two iterators have a slight performance disadvantage to one.