Static Reflection in .NET, part 2

• Posted by Kris Vandermotten on December 31, 2009
• 18 comments

A few weeks ago, I talked about static reflection and its advantages. You’ll remember that the main advantages, compared to the normal reflection API’s, are the compile time checking of parameters and IntelliSense support.

How does it compare at other levels, performance for example? Before we dive into that question, let me state that performance may or may not be important to you. A program that is fast enough is, well, fast enough. It’s unlikely that a (single) reflection call will have a significant impact on, say, the response time of a graphical user interface, and so performance doesn’t matter. If you’re algorithm requires millions of reflection operations, I’m sure you can rewrite it somehow to reduce that number significantly, and then performance again probably doesn’t matter anymore. That being said, we still want to know, right?

First of all, let’s compare code.

Take this line (using the Example class from the last post):

PropertyInfo pi = typeof(Example).GetProperty("Description");

This line compiles to the following IL (simplified for readability):

ldtoken Example 
call class Type Type::GetTypeFromHandle(valuetype RuntimeTypeHandle) 
ldstr "Description" 
call instance class PropertyInfo Type::GetProperty(string)

Compare that to the following line:

PropertyInfo pi = StaticReflector.Create<Example>().PropertyInfo(e => e.Description);

Which compiles to:

call class IStaticReflector`1<!!0> StaticReflector::Create<class Example>()
ldtoken Example
call class Type Type::GetTypeFromHandle(valuetype RuntimeTypeHandle)
ldstr "e"
call class ParameterExpression Expression::Parameter(class Type, string)
stloc.0 
ldloc.0 
ldtoken instance string Example::get_Description()
call class MethodBase MethodBase::GetMethodFromHandle(valuetype RuntimeMethodHandle)
castclass MethodInfo
call class MemberExpression Expression::Property(class Expression, class MethodInfo)
ldc.i4.1 
newarr ParameterExpression
stloc.1 
ldloc.1 
ldc.i4.0 
ldloc.0 
stelem.ref 
ldloc.1 
call class Expression`1<!!0> Expression::Lambda<class System.Func`2<class Example, string>>(class Expression, class ParameterExpression[])
call class PropertyInfo StaticReflectorExtensions::PropertyInfo<class Example, string>(class IStaticReflector`1<!!0>, class Expression`1<class System.Func`2<!!0, !!1>>)

As you can see, this code doesn’t load the “Description” string, it uses the ldtoken instruction instead. Some bloggers have suggested that this would make it more efficient. Unfortunately, even if the ldtoken instruction is efficient, it is largely offset by the construction of the lambda expression. I ran a little benchmark, in which I compare execution time (in ticks) and memory usage (in generation 0 garbage collection runs) of both approaches, executing each one a million times. This is the result (on my laptop):

Using Reflection       Time:    1089308 Collections:    45
Using StaticReflection Time:   13513777 Collections:   264

As you can see, the Static Reflection approach is about 13.5 times slower than the good old dynamic reflection, and it uses a lot more memory. That should be no surprise either: both cases allocate a PropertyInfo object, but the static case also allocates the expression, which is nothing but food for the garbage collector.

So, one approach seems good at compile time, and the other is good at run time. It seems we’re stuck between a rock and a hard place. But the situation isn’t so bad: we have two options to choose from, each with their pro’s and con’s. What the best one is depends on your requirements, and what you value the most: compile time checking (which may result in productivity and maintainability benefits), or performance.

And who knows, maybe there is a third option, giving the best of both worlds. But that’s for next time.

String.Trim() fixed in .NET 4.0

• Posted by Kris Vandermotten on November 11, 2009
• 60 comments

A long time ago, I wrote a blog post about the problems with String.Trim(). I’m happy to see that all three issues have been addressed in the .NET Framework 4.0.

To start with, Trim() will now be consistent with Char.IsWhiteSpace(). Theoretically, this is a breaking change, but I don’t expect many programs to have a problem with this change. Note that the change is very well documented in the online help.

Secondly, the code of Trim() has been cleaned up considerably. A string that consists entirely of whitespace is no longer scanned twice. I haven’t done any benchmarks, but I expect the performance to be at least as good as for the same function in .NET 2.0 – 3.5.

Last but not least, the frequent abuse of the Trim() function to simply validate strings will greatly decrease with the introduction of the static IsNullOrWhitespace(string value) function, which is much faster than calling Trim().

It’s a small detail, compared to all the other goodies .NET 4.0 brings, but a good addition to the toolbox nonetheless.

Static Reflection in .NET

• Posted by Kris Vandermotten on October 11, 2009
• 63 comments

LINQ expressions have proven to be extremely versatile, popping up in all sorts of areas. “Static Reflection” seem to be the latest hype. But what is static reflection anyway, and why is it good or why is it bad?

Reflection is used to obtain information about the code you are executing, and to use that information to interact with the code dynamically. Sometimes reflection is used to interact dynamically with code that is statically known by a program already. For example, data binding heavily relies on reflection to dynamically read and write properties. The calling program knows about those properties statically, but the data binding libraries do not. In data binding, object properties are often identified by their name, expressed as a string. That string is then used by the libraries to construct a PropertyInfo object.

Time for an example. Given this class:

public class Example
{
    public string Description { get; set; }
}

You can obtain a PropertyInfo object describing the Description property as follows:

PropertyInfo pi = typeof(Example).GetProperty("Description");

We may have an issue here. If I make a typing mistake in the GetProperty call, I don’t get a compiler error. At runtime, the call will return null, probably leading to a NullReferenceException down the road. And of course, Visual Studio Intellisense will not help me to type it right. Also, if I rename the property, for example to “Summary”, the GetProperty call will be broken, without a compile-time error. Static Reflection is one technique to avoid these issues.

Using LINQ expressions, we could create an API that allows us to do something like the following:

PropertyInfo pi = StaticReflector.GetProperty(Example e => e.Description);

The downside of this approach is that it doesn’t work with anonymous types. So I propose a different mechanism. What we need is something that statically gives us access to a type. Any generic interface will do. I propose the following:

public interface IStaticReflector<T>
{
}

Given this interface, we can define a series of extension methods, for example:

public static class StaticReflectorExtensions
{
    public static PropertyInfo PropertyInfo<T, U>(this IStaticReflector<T> obj, Expression<Func<T, U>> selector)
    {
        var body = selector.Body as MemberExpression;
        return body.Member as PropertyInfo;
    }
}

Notice how the obj parameter is not really used in the PropertyInfo method. It does serve a purpose however: it allows us to use type inference on the type T, and I get full Intellisense. For example:

IStaticReflector<Example> reflector = null;
PropertyInfo pi = reflector.PropertyInfo(e => e.Description);

Granted, initializing a variable to null and then calling a method on it is a bit weird. We need a more elegant way to create these things:

public static class StaticReflector
{
    public static IStaticReflector<T> Create<T>()
    {
        return null;
    }
}

Now we can write:

PropertyInfo pi = StaticReflector.Create<Example>().PropertyInfo(e => e.Description);

This still doesn’t work on anonymous types though. For those, we could use the following:

public static class ObjectExtensions
{
    public static IStaticReflector<T> GetReflector<T>(this T obj)
    {
        return null;
    }
}

Now we can write things such as:

var anonymous = new { Description = "Example" };

PropertyInfo pi = anonymous.GetReflector().PropertyInfo(e => e.Description);

I do prefer the StaticReflector.Create<T>() method is case the type name is known though.

Are we done? Not really. Let’s go back to dynamic reflection using string names. Lot’s of things could go wrong there, and we don’t get any warnings. The situation has not gone worse, but still lot’s of things can go wrong. So the PropertyInfo method needs some parameter validation. Also, properties certainly aren’t the only thing we can reflect upon. What about fields, methods and constructors? Here’s a full implementation:

using System;
using System.Linq.Expressions;
using System.Reflection;

public static class StaticReflectorExtensions
{
    public static PropertyInfo PropertyInfo<T, U>(this IStaticReflector<T> obj, Expression<Func<T, U>> selector)
    {
        if (selector == null)
        {
            throw new ArgumentNullException(Strings.Selector);
        }

        PropertyInfo pi = obj.MemberInfo(selector) as PropertyInfo;

        if (pi == null)
        {
            throw new ArgumentException(Strings.InvalidPropertySelector, Strings.Selector);
        }

        return pi;
    }

    public static FieldInfo FieldInfo<T, U>(this IStaticReflector<T> obj, Expression<Func<T, U>> selector)
    {
        if (selector == null)
        {
            throw new ArgumentNullException(Strings.Selector);
        }

        FieldInfo fi = obj.MemberInfo(selector) as FieldInfo;

        if (fi == null)
        {
            throw new ArgumentException(Strings.InvalidFieldSelector, Strings.Selector);
        }

        return fi;
    }

    public static MemberInfo MemberInfo<T, U>(this IStaticReflector<T> obj, Expression<Func<T, U>> selector)
    {
        if (selector == null)
        {
            throw new ArgumentNullException(Strings.Selector);
        }

        var body = selector.Body as MemberExpression;

        if (body == null)
        {
            throw new ArgumentException(Strings.InvalidMemberSelector, Strings.Selector);
        }

        if (body.Expression.NodeType != ExpressionType.Parameter)
        {
            throw new ArgumentException(Strings.InvalidMemberSelector, Strings.Selector);
        }

        return body.Member;
    }

    public static MethodInfo MethodInfo<T, U>(this IStaticReflector<T> obj, Expression<Func<T, U>> selector)
    {
        if (selector == null)
        {
            throw new ArgumentNullException(Strings.Selector);
        }

        var body = selector.Body as MethodCallExpression;

        if (body == null)
        {
            throw new ArgumentException(Strings.InvalidMethodSelector, Strings.Selector);
        }

        // instance methods must be called on the parameter
        if (body.Object != null && body.Object.NodeType != ExpressionType.Parameter)
        {
            throw new ArgumentException(Strings.InvalidMethodSelector, Strings.Selector);
        }

        // static methods must be defined in the type of the parameter or a base type
        if (body.Object == null && !body.Method.DeclaringType.IsAssignableFrom(typeof(T)))
        {
            throw new ArgumentException(Strings.InvalidMethodSelector, Strings.Selector);
        }

        return body.Method;
    }

    public static MethodInfo MethodInfo<T>(this IStaticReflector<T> obj, Expression<Action<T>> selector)
    {
        if (selector == null)
        {
            throw new ArgumentNullException(Strings.Selector);
        }

        var body = selector.Body as MethodCallExpression;

        if (body == null)
        {
            throw new ArgumentException(Strings.InvalidMethodSelector, Strings.Selector);
        }

        // instance methods must be called on the parameter
        if (body.Object != null && body.Object.NodeType != ExpressionType.Parameter)
        {
            throw new ArgumentException(Strings.InvalidMethodSelector, Strings.Selector);
        }

        // static methods must be defined in the type of the parameter or a base type
        if (body.Object == null && !body.Method.DeclaringType.IsAssignableFrom(typeof(T)))
        {
            throw new ArgumentException(Strings.InvalidMethodSelector, Strings.Selector);
        }

        return body.Method;
    }

    public static ConstructorInfo ConstructorInfo<T>(this IStaticReflector<T> obj, Expression<Func<T>> selector)
    {
        if (selector == null)
        {
            throw new ArgumentNullException(Strings.Selector);
        }

        var body = selector.Body as NewExpression;

        if (body == null)
        {
            throw new ArgumentException(Strings.InvalidConstructorSelector, Strings.Selector);
        }

        return body.Constructor;
    }

    private static class Strings
    {
        internal const string InvalidFieldSelector = "Invalid field selector";
        internal const string InvalidPropertySelector = "Invalid property selector";
        internal const string InvalidMemberSelector = "Invalid member selector";
        internal const string InvalidMethodSelector = "Invalid method selector";
        internal const string InvalidConstructorSelector = "Invalid constructor selector";
        internal const string Selector = "selector";
    }
}

Next time, we’ll talk about the disadvantages of this approach, and we’ll look at an alternative.

Paint.NET Effects updated

• Posted by Kris Vandermotten on April 28, 2009
• 18 comments

StyleCop for C# released

• Posted by Kris Vandermotten on May 31, 2008
• 16 comments

.NET 3.5 SP1 Beta available

• Posted by Kris Vandermotten on May 5, 2008
• 60 comments

Having fun with Linq to Nullable types

• Posted by Kris Vandermotten on April 21, 2008
• 69 comments

static double? Add(double? x, double? y) 

{

     return x + y; 

}

static double? Add(double? x, double? y) 

{

    return x.HasValue && y.HasValue ? new double?(x.GetValueOrDefault() + y.GetValueOrDefault()) : null; 

}

static double? Abs(double? x) 

{

     return Math.Abs(x); // won't compile 

}

static double? Abs(double? x) 

{

     return from d in x select Math.Abs(d); 

}

public static T? Select<T>(this T? x, Func<T, T> selector)

     where T : struct 

{

     return x.HasValue ? new T?(selector(x.Value)) : null; 

}

public static T? Where<T>(this T? source, Func<T, bool> predicate)

     where T : struct 

{

     return source.HasValue && predicate(source.Value) ? source : null; 

}

static double? Asin(double? x) 

{

     return from d in x where d >= -1 && d <= 1 select Math.Asin(d); 

}

public static V? SelectMany<T, U, V>(this T? source, Func<T, U?> k, Func<T, U, V> resultSelector)

     where T : struct

     where U : struct

     where V : struct 

{

     if (k == null)

     {

         throw new ArgumentNullException("k");

     }

     if (resultSelector == null)

     {

         throw new ArgumentNullException("resultSelector");

     }

     return source.HasValue && k(source.Value).HasValue ?

          new V?(resultSelector(source.Value, k(source.Value).Value)) : null; 

}

static double? SinCos(double? x, double? y) 

{

     return from xd in x

            from yd in y

            select Math.Sin(xd) * Math.Cos(yd); 

}

AssemblyInfo updated

• Posted by Kris Vandermotten on April 16, 2008
• 51 comments

PaintDotNetEffects updated for Paint.NET 3.30

• Posted by Kris Vandermotten on March 4, 2008
• 77 comments

Lightweight Code Generation with Linq Expressions

• Posted by Kris Vandermotten on March 4, 2008
• 59 comments

Linq expressions are the key ingredient behind the IQueryable<T> interface. One aspect of them, largely underestimated if you ask me, is the fact they can be compiled into executable code at runtime.

Let's look at a concrete example: a generic comparer, which compares objects based on one of their properties. Take a Person class, with a Name property (amongst others), and you want to sort a List<Person> by Name. Sure, if you statically know, at compile time that is, the property on which to sort, you can simply use the Linq orderby operator and pass it the Lambda to extract the property value. But what if you don't know the property statically? What if you need to be able to sort any type on any of its properties?

In that case you need a way to extract the property dynamically. Reflection can do the job, but it's slow. With Reflection.Emit you can generate a DynamicMethod, but Expressions provide an easier alternative.

The function I need will have three parameters:

var x = Expression.Parameter(typeof(TObject), "x");
var y = Expression.Parameter(typeof(TObject), "y");
var c = Expression.Parameter(typeof(IComparer<TProperty>), "c");

Given a PropertyInfo (or just a name) for the property, I can generate and expression for the function and compile it:

compare = Expression.Lambda<Func<TObject, TObject, IComparer<TProperty>, int>>

     (

         Expression.Call(

             c,

             "Compare", null,

             Expression.Property(x, propertyInfo),

             Expression.Property(y, propertyInfo)),

         x, y, c

     ).Compile();

That's really all there is to it. I can then wrap this function into an IComparer<TObject>, as shown below.

Why bother? Sure, generation of the comparer will take its fair share of CPU cycles. But execution of the comparer will be a lot faster. When I need to sort, say, 10 objects, it doesn't matter, that will be done quickly enough either way. But when I need to sort thousands of objects, this technique can offer a significant speedup.

And what alternatives do I have? I could use DynamicMethod, which is what I used to do before .NET 3.5. In fact, that's exactly what the Compile() method on an expression is doing. The generated function would be no different, but the generation code definitely is more difficult and error prone to write. Both options share the fact that I'm doing a delegate call for every comparison. I could get rid of that delegate call by generating a full assembly using Reflection.Emit. But then I need to worry about memory leaks, because I can't unload the assembly.

Expressions aren't as powerful as the raw DynamicMethod, but they're easier to use. That's why I prefer them over DynamicMethod whenever I can.

Full source code for the example, including a SortedBindingList<T> that uses PropertyComparer<T>:

using System; 

using System.Collections.Generic; 

using System.ComponentModel;

using System.Linq.Expressions; 

using System.Reflection;  

namespace Vandermotten.Collections.Generic 

{

    public class PropertyComparer<TObject>

    {

        public static IComparer<TObject> Create(string propertyName)

        {

            return Create(propertyName, ListSortDirection.Ascending);

        }

        public static IComparer<TObject> Create(string propertyName, ListSortDirection direction)

        {

             return Create(typeof(TObject).GetProperty(propertyName), direction);

        }

        public static IComparer<TObject> Create(PropertyInfo propertyInfo)

        {

            return Create(propertyInfo, ListSortDirection.Ascending);

        }

        public static IComparer<TObject> Create(PropertyInfo propertyInfo, ListSortDirection direction)

        {

            if (propertyInfo == null)

            {

                throw new ArgumentNullException("propertyInfo");

            }

            if (!propertyInfo.CanRead)

            {

                throw new ArgumentException("Cannot read property " + propertyInfo.Name);

            }

            Type cT = typeof(Comp<>).MakeGenericType(typeof(TObject), propertyInfo.PropertyType);

            return (IComparer<TObject>)Activator.CreateInstance(cT, propertyInfo, direction);

        }

        private class Comp<TProperty> : IComparer<TObject>

        {

            private Comparer<TProperty> comparer;

            public Comp(PropertyInfo propertyInfo, ListSortDirection direction)

            {

                comparer = Comparer<TProperty>.Default;

                var x = Expression.Parameter(typeof(TObject), "x");

                var y = Expression.Parameter(typeof(TObject), "y");

                var c = Expression.Parameter(typeof(IComparer<TProperty>), "c");

                if (direction == ListSortDirection.Ascending)

                {

                    compare = Expression.Lambda<Func<TObject, TObject, IComparer<TProperty>, int>>

                        (

                            Expression.Call(

                                c,

                                "Compare", null,

                                Expression.Property(x, propertyInfo),

                                Expression.Property(y, propertyInfo)),

                            x, y, c

                        ).Compile();

                }

                else

                {

                    compare = Expression.Lambda<Func<TObject, TObject, IComparer<TProperty>, int>>

                        (

                            Expression.Call(

                                c,

                                "Compare", null,

                                Expression.Property(y, propertyInfo),

                                Expression.Property(x, propertyInfo)),

                            x, y, c

                        ).Compile();

                }

            }

            Func<TObject, TObject, IComparer<TProperty>, int> compare;

            public int Compare(TObject x, TObject y)

            {

                return compare(x, y, comparer);

            }

        }

    } 

    public class SortedBindingList<T> : BindingList<T>

    { 

        private bool sorted; 

        private ListSortDirection sortDirection = ListSortDirection.Ascending; 

        private PropertyDescriptor sortProperty; 

        public SortedBindingList() 

        { 

        }  

        public SortedBindingList(List<T> list) 

            : base (list) 

        { 

        }

        protected override void ApplySortCore(PropertyDescriptor prop, ListSortDirection direction) 

        { 

            List<T> items = Items as List<T>; 

            if (items != null) 

            { 

                sortDirection = direction; 

                sortProperty = prop; 

                IComparer<T> pc = PropertyComparer<T>.Create(prop.Name, direction); 

                items.Sort(pc); 

                sorted = true; 

            } 

            else 

            { 

                sorted = false; 

            } 

        } 

        protected override void RemoveSortCore() 

        { 

            sorted = false; 

        } 

        protected override bool SupportsSortingCore 

        { 

            get { return true; } 

        } 

        protected override bool IsSortedCore 

        { 

            get { return sorted; } 

        } 

        protected override ListSortDirection SortDirectionCore 

        { 

            get { return sortDirection; } 

        } 

        protected override PropertyDescriptor SortPropertyCore 

        { 

            get { return sortProperty; } 

        } 

    } 

}