File size

File size

File size

Meet Luke Hoban, Program Manager on the C# Compiler team. Here, we talk about how LINQ works, from a compiler point of view. As you know by now, LINQ is a construct that is built of new language level innovations which of course must have compiler support...
As you might imagine, given the nature of LINQ's requisite language level components, we talk about functional programming and it's new role in our good old imperative world. In Orcas, you shouldn't talk about LINQ without showing it in action inside of Visual
Studio.

Enjoy.

For the detail-oriented folks out there: I shot this interview a few months ago, so you'll hear references to the Feb/March CTP. Have no fear, Niners, the content in this interview is as pertinent now as it was then (even more so with the release of Orcas beta
1).

Way to go Charles, @ 18:10 whipping out the Distinct keyword! I really have to sharpen-up my linq skills. When I first used Orcas, I was disturbed how aggressively intelisense was in investigating my code. However, it saves a tremendous amount of time,
which would otherwise be wasted staring at a blinking pipe. The results of better integration between the IDE and the compiler are truly impressive.

If anybody know, I would be very thankful if someone could explain me speed implications of the LINQ.

I've watche the video and it seems LINQ uses a lot of lambda functions, which I suspect are stack based. So are the linq expressions as fast as normal hand coded loops or they abuse stack and are thus slow. Can JIT compiler/Linq somehow inline those lambda
functions to avoid suffering from stack over-use?

Or in other words, can I use linq for some serious math computations as a replacement for 'while' and 'for' statement?

Inlining probably won't happen, because the JIT compiler would have to inline all the
.Where, .Group,
.Sort and .Select calls and those are definitely not short functions.Apart from that, LINQ over in-memory structures is written against interfaces (if I'm not mistaken) and therefor uses virtual calls all over the place.And yes, the lambda expressions are called via delegates.

﻿Inlining probably won't happen, because the JIT compiler would have to inline all the
.Where, .Group,
.Sort and .Select calls and those are definitely not short functions.Apart from that, LINQ over in-memory structures is written against interfaces (if I'm not mistaken) and therefor uses virtual calls all over the place.And yes, the lambda expressions are called via delegates.

Hmmm. The .Where, .Group, .Sort, ... methods are defined in static classes (the in memory that come with .NET 3.5 - Enumerable is the static class name) and therefore in static methods. I think they can be inlined without any problems (They are also not that
long, because they return only an IQueryable instance). The lambda expressions itself are very short and good candidates for inlining.

I wonder if somebody from the team could jump into this discussion and bring some light to it.

People who'd like to build building custom query providers for LINQ using the IQueryable interface might be interested to check out my blog series on
LINQ to LDAP. Another interesting project might be
LINQ to SharePoint on CodePlex. If you want to get some insight in the standard query operators from LINQ to Objects, check out the
LINQ-SQO project.

Apart from type inference of parameters, what do lamba functions add to anonymous methods? In the example Luke showed on the whiteboard, instead of generating array.Select( i => i*i), the compiler could have generated array.Select(delegate (int i) { return
i*i;} );. Of course, it would have to know at that point that i is an int, but it would have to know about it eventually, even with lambda functions. I guess it makes the compiler design simpler to do it in two separate steps?

I'd say lambda expressions have two major benefits over anonymous methods. First, they are syntactically more concise. Since the functions defined by lambdas or anonymous methods are most often needed in-line as part of a larger expression - it's important
to have a good concise syntax. Otherwise, the code quickly becomes very difficult to read. So a major goal for lambdas was to provide a really concise and readable way to declare these small functions in-line.

The other benefit is the type inference you mention. This also helps with conciseness - but more importantly it avoids littering the type names all over a single simple expression, which can become a significant syntactic issue for many uses of lambdas.

At a higher level - the emphasis on lambdas is actually much more general than LINQ. We see many new APIs looking to provide the kind of level of abstraction that really requires taking delegates as arguments - and LINQ is just one example. I definitely expect
to see more of these APIs in other interesting domains over the coming months/years.

Remove this comment

Remove this thread

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.