In-Memory Query with C#2.0 and C#3.0

Here's some sample code from a demo I did a few months ago.  It's a simple example of how much easier in-memory query and transformation are with C#3.0 and LINQ, compared with a straightforward implementation using C#2.0.

The Query

The goal is to implement this query:

"Get all the instance methods on System.String, ordered by name and grouped into overloads, each with the name of the overloaded member and the number of overloads."

For example, you can imagine that a C# editor IntelliSense implementation might need code such as this one to present a completion list on an instance of System.String.

C# 2.0 Implementation

MethodInfo[] methods = typeof(string).GetMethods();

List<MethodInfo> instanceMethods = new List<MethodInfo>();
foreach (MethodInfo method in methods)
if (!method.IsStatic)
instanceMethods.Sort(delegate(MethodInfo m1, MethodInfo m2) { return m1.Name.CompareTo(m2.Name); });
Dictionary<string, List<MethodInfo>> methodGroups = new Dictionary<string, List<MethodInfo>>();
foreach (MethodInfo method in instanceMethods)
if (methodGroups.ContainsKey(method.Name))
methodGroups.Add(method.Name, new List<MethodInfo>());
List<Container> result = new List<Container>();
foreach (string name in methodGroups.Keys)
Container container = new Container();
container.MethodName = name;
container.Overloads = methodGroups[name].Count;
foreach (Container item in result)

C# 3.0 Implementation

MethodInfo[] methods = typeof(string).GetMethods();

var query =
from m in methods
where !m.IsStatic
orderby m.Name
group m by m.Name into g
select new { MethodName = g.Key, Overloads = g.Count() };

foreach (var item in query)


The C#3.0 implementation is quite a bit shorter!  But more importantly, it reads a lot like the English description of the query given above.   It's also a more declarative description of the query - it says what to do, but not how to do it.  These are general features of using LINQ to Objects with C#3.0.  There are many cases where what would have been for loops, if statements, and assignments to intermediate collections - can now be written as queries, providing a clearer description of what the code is doing.

BTW - Which do you think is faster?  Why?

kick it on

Comments (12)
  1. You’ve been kicked (a good thing) – Trackback from

  2. Recently my time has been taken up with a series of internal issues involving Beta1, C# Samples and various

  3. ElDog says:

    About the speed – the queue is based on generic operators, all "smart things" are performed on compile time so, carefully speaking, the queue shouldn’t be much slower than the first, straightforward implementation.

  4. A few weeks back, Soma blogged about an increased investment by the Microsoft Developer Division in the

  5. Luke Hoban is now full time as program manager on F#, and has just posted a short introduction about

  6. Luke Hoban is now full time as program manager on F#, and has just posted a short introduction about

  7. Luke Hoban is now full time as program manager on F#, and has just posted a short introduction about

  8. dave^2=-1 says:

    LukeH has a good example of how simple and expressive LINQ queries can be compared to more traditional

  9. Justin.Th says:

    Hi Luke,

    I think there is a slight bug in the C# 2.0 implementation in that you are relying on the ordering of the Dictionary.Keys collection to be the same as what was inserted. This may work in practice, but according to the docs:

    The order of the keys in the Dictionary<(Of <(TKey, TValue>)>).KeyCollection is unspecified

    Perhaps you should use a SortedDictionary and ditch the sort on the list of MethodInfos?

    I suppose it just goes to further demonstrate the beauty of C# 3.0: the code is terser, the objective of the code is more obvious and it is easier to get right!

  10. Propecia. Cheap propecia. Propecia online uk.

  11. graffic says:

    The second implementation is much slower. But let’s explain why.

    LINQ was made to embed SQL into the code. Therefore it was supposed to use all the database "good things" to do the job.

    For me the only database good things are "indexes". The way to access one record in a million in less than 0.1 seconds. Therefore when LINQ is translated in a SQL query of an indexed database we obtain:

    1. good performance

    2. good readability.

    But some times we need to handle in memory data. In that case we thing "hey! let’s use linq again" But think now "who is gonna support your efforts when making queries?". The answer is nobody.

    There is no special software for LINQ to objects. Then what linq does is to "sweep" the data structure collecting members that match your query.

    Of course this is slow as hell if you compare it with a dictionary.

    If you’re gonna do it once. Is ok to wait because we will suffer it only once. But if the query is in a loop. You’re delete the code after the second run because is just too much time.

Comments are closed.

Skip to main content