
Expressions in C # - impress yourself!
.NET 4.0 is just around the corner and will bring a bunch of new, necessary and not very cool and super cool. However, in the good old .NET 3.5, there are many different interesting features that are not used in everyday work, but sometimes make life easier for developers. One of these great things is Expressions.
Expressions (or, rather, expression trees) is nothing more than an expression tree familiar from university days when you were just learning to program. Here is the napirmer, the tree for the expression 2 + 3 * 4.
System.Linq.Expressions, in principle, are the same trees, only bigger and more complex (in total there are 56 different expressions in .NET, starting with simple mathematical expressions, ending with initializing lists and calling methods).

Expressions can be built in two ways - in compile-time, and in run-time. In compile-time, the compiler will parse our code and compile Expression from it. For example, for this line:
the compiler will actually produce this code:
Thus, we get access to the internal structure of the expression and can map it to some external language - in particular, LINQ to SQL works, which parses the received expression (I said that LINQ query is actually a chain of calls and also translates into expression ?) and executes the corresponding T-SQL query. I will not tell how this is done - this requires a new article.
I want to talk about the second way to build expressions - in run-time. For example, we are faced with the task of writing a deserializer that will collect an object by a set of pairs “property name”: “value”. The standard way to solve the problem is reflection, which, as you know, is very slow. Here is the creator’s code through reflection (I won’t explain, everything should be clear):
This creator spends 0.001 sec on creating the creator and 1.20 sec on creating 10,000 objects (yes, creating the creator ...). Long, but not fatal. But let's take a look from the side of expressions.
Let's take a closer look at the problem. If we were faced with the task of writing a deserializer for a specific class, for example, for the Foo class:
we could just collect the functor we need, like this:
Where GetValue () is the extension method for the dictionary:
We already know that, in principle, any piece of code can be represented as an expression tree simply by replacing Func <> with Expression>. Let's take a look at what the compiler will show us when we wrap this functor in an expression (I apologize for the sheet, but it's hard to explain without it):
Let's try to figure it out.
1. Parameter for our expression (which is logical, because our factor also takes one parameter).
2. Our expression is a lambda expression from a functor.
4. We initialize the members of class
6-10. ... calling the constructor without parameters
11. ... and with the following set of initializers:
13-15. Foo.Name
16. ... whose value is obtained as a result of calling method
18. ... static
19. ... DictionaryExtension.GetValue (note, calling the extension method is not different from calling the static method)
20. ... with parameters
22. ... d , which will be passed to us as a parameter of the functor
23. ... and a lowercase constant parameter “Name”, which is nothing more than the name of the property
27-40. All the same for Foo.Value
43. Actually, the parameter itself for the functor.
I think it’s quite clear that we can repeat this code, only substitute the assembled one for this type instead of the MemberBindings [] hardcode array. After that, we will only have to somehow execute this expression. To do this, there is a remarkable LambdaExpression Compile () method, which compiles our functor from the expression.
Here is the code for our new creator:
We, in fact, repeat the code created by the compiler, but dynamically process all the properties of any given object. (The construction is completely analogous to the analysis above).
A new creator is created 0.01 seconds (which is 10 times slower than reflection, but the constructor is called only once) and spends 0.017 seconds to create 10,000 objects (which is 70 times faster).
By the way, if you create a Foo object directly
then this is only two times faster than through expressions.
These things allow us to make Expression trees.
The source text can be found here: tyts .

Expressions can be built in two ways - in compile-time, and in run-time. In compile-time, the compiler will parse our code and compile Expression from it. For example, for this line:
Expression> ex = s => s.Replace("x", "yy").Length*2;
* This source code was highlighted with Source Code Highlighter.
the compiler will actually produce this code:
ParameterExpression CS$0$0000;
Expression> ex = Expression.Lambda>(Expression.Multiply(Expression.Property(Expression.Call(CS$0$0000 = Expression.Parameter(typeof(string), "s"), (MethodInfo) methodof(string.Replace), new Expression[] { Expression.Constant("x", typeof(string)), Expression.Constant("yy", typeof(string)) }), (MethodInfo) methodof(string.get_Length)), Expression.Constant(2, typeof(int))), new ParameterExpression[] { CS$0$0000 });
* This source code was highlighted with Source Code Highlighter.
Thus, we get access to the internal structure of the expression and can map it to some external language - in particular, LINQ to SQL works, which parses the received expression (I said that LINQ query is actually a chain of calls and also translates into expression ?) and executes the corresponding T-SQL query. I will not tell how this is done - this requires a new article.
I want to talk about the second way to build expressions - in run-time. For example, we are faced with the task of writing a deserializer that will collect an object by a set of pairs “property name”: “value”. The standard way to solve the problem is reflection, which, as you know, is very slow. Here is the creator’s code through reflection (I won’t explain, everything should be clear):
internal class ReflectionCreator:ICreator
{
private readonly List _infos;
public ReflectionCreator()
{
_infos = new List(typeof(T).GetProperties(BindingFlags.Instance | BindingFlags.Public | BindingFlags.SetProperty));
}
public T Create(Dictionary props)
{
var newObject = Activator.CreateInstance();
foreach (var propertyInfo in _infos)
{
object value;
if (props.TryGetValue(propertyInfo.Name, out value))
{
propertyInfo.SetValue(newObject, value, null);
}
}
return newObject;
}
}
* This source code was highlighted with Source Code Highlighter.
This creator spends 0.001 sec on creating the creator and 1.20 sec on creating 10,000 objects (yes, creating the creator ...). Long, but not fatal. But let's take a look from the side of expressions.
Let's take a closer look at the problem. If we were faced with the task of writing a deserializer for a specific class, for example, for the Foo class:
class Foo
{
public string Name { get; set; }
public int Value { get; set; }
}
* This source code was highlighted with Source Code Highlighter.
we could just collect the functor we need, like this:
Func, Foo> fooCreator =
d => new Foo
{
Name = d.GetValue("Name"),
Value = d.GetValue("Value")
};
* This source code was highlighted with Source Code Highlighter.
Where GetValue () is the extension method for the dictionary:
static class DictionaryExtension
{
public static TType GetValue(this Dictionary d, string name)
{
object value;
return d.TryGetValue(name, out value) ? (TType)value : default(TType);
}
}
* This source code was highlighted with Source Code Highlighter.
We already know that, in principle, any piece of code can be represented as an expression tree simply by replacing Func <> with Expression
- ParameterExpression CS0 = Expression.Parameter(typeof (Dictionary
), "d"); - var fooCreator = Expression.Lambda
, Foo>> - (
- Expression.MemberInit
- (
- Expression.New
- (
- (ConstructorInfo)methodof(Foo..ctor),
- new Expression[0]
- ),
- new MemberBinding[]
- {
- Expression.Bind
- (
- (MethodInfo)methodof(Foo.set_Name),
- Expression.Call
- (
- null,
- (MethodInfo)methodof(DictionaryExtension.GetValue),
- new Expression[]
- {
- CS0,
- Expression.Constant("Name",typeof(string))
- }
- )
- ),
- Expression.Bind
- (
- (MethodInfo)methodof(Foo.set_Value),
- Expression.Call
- (
- null,
- (MethodInfo)methodof(DictionaryExtension.GetValue),
- new Expression[]
- {
- CS0,
- Expression.Constant("Value",typeof(string))
- }
- )
- )
- }
- ),
- new ParameterExpression[] {CS0}
- );
* This source code was highlighted with Source Code Highlighter.
Let's try to figure it out.
1. Parameter for our expression (which is logical, because our factor also takes one parameter).
2. Our expression is a lambda expression from a functor.
4. We initialize the members of class
6-10. ... calling the constructor without parameters
11. ... and with the following set of initializers:
13-15. Foo.Name
16. ... whose value is obtained as a result of calling method
18. ... static
19. ... DictionaryExtension.GetValue (note, calling the extension method is not different from calling the static method)
20. ... with parameters
22. ... d , which will be passed to us as a parameter of the functor
23. ... and a lowercase constant parameter “Name”, which is nothing more than the name of the property
27-40. All the same for Foo.Value
43. Actually, the parameter itself for the functor.
I think it’s quite clear that we can repeat this code, only substitute the assembled one for this type instead of the MemberBindings [] hardcode array. After that, we will only have to somehow execute this expression. To do this, there is a remarkable LambdaExpression Compile () method, which compiles our functor from the expression.
Here is the code for our new creator:
class ExpressionCreator : ICreator
{
private readonly Func, T> _creator;
public ExpressionCreator()
{
var type = typeof(T);
var newExpression = Expression.New(type);
var dictParam = Expression.Parameter(typeof(Dictionary), "d");
var list = new List();
var propertyInfos = type.GetProperties(BindingFlags.Instance |
BindingFlags.Public |
BindingFlags.SetProperty);
foreach (var propertyInfo in propertyInfos)
{
Expression call = Expression.Call(
typeof (DictionaryExtension),
"GetValue", new[] {propertyInfo.PropertyType},
new Expression[]
{
dictParam,
Expression.Constant(propertyInfo.Name)
});
MemberBinding mb = Expression.Bind(propertyInfo.GetSetMethod(), call);
list.Add(mb);
}
var ex = Expression.Lambda, T>>(
Expression.MemberInit(newExpression, list),
new[] {dictParam});
_creator = ex.Compile();
}
public T Create(Dictionary props)
{
return _creator(props);
}
}
* This source code was highlighted with Source Code Highlighter.
We, in fact, repeat the code created by the compiler, but dynamically process all the properties of any given object. (The construction is completely analogous to the analysis above).
A new creator is created 0.01 seconds (which is 10 times slower than reflection, but the constructor is called only once) and spends 0.017 seconds to create 10,000 objects (which is 70 times faster).
By the way, if you create a Foo object directly
internal class DirectCreator : ICreator
{
public Foo Create(Dictionary props)
{
return new Foo
{
Name = props.GetValue("Name"),
Value = props.GetValue("Value")
};
}
}
* This source code was highlighted with Source Code Highlighter.
then this is only two times faster than through expressions.
These things allow us to make Expression trees.
The source text can be found here: tyts .