Dynamic Object Instantiation: Performance

Sometimes we write code that we know has performance issues, making a mental note to “come back” and really refactor it later to get the most bang for the buck. We do this because of deadlines, because we can’t figure out any other way at the moment it needs to be done, or we are simply lazy sometimes and tend to implement code in a manner we are familiar with and understand.

While I don’t necessarily think this is always bad as some purists might, I do think that we should always make it a point to eventually revisit these performance nightmares, as often we learn more by diving into alternative ways to solve old problems than by solving new problems.

One particular glaring example for me has always been the use of Activator.CreateInstance. It’s soooo easy to use and seems to run fairly fast, assuming one isn’t creating a billion objects. Most business applications don’t come anywhere near requiring this type of performance, so I’ve always just taken the easy way out. However I got a bug in pants today to revisit this reflection nightmare and see if I couldn’t come up with a way to speed it up or find an alternative.

Here’s what my normal code would look like:

 

    public static class Proxy<T>

    {

        public static T CreateNew(int id)

        {

            return (T)Activator.CreateInstance(typeof(T), new object[] { id });

        }

    }

So when we use this, we’d simply say something like TestClass tc = Proxy<TestClass>.CreateNew(10); And that’s all fine and dandy, except the performance for large numbers of objects can be terribly slow (how slow?…we’ll see in a bit).

So my first idea was to use my old trusty friend, Mr. Cache. I figured I could cache the ConstructorInfo object representing the constructor for each various type that my generic Proxy<T> class might call. Then just reuse that same ConstructorInfo object by invoking it directly when new instances needed to be created of that type. So this is what I got:

  

    public static class Proxy<T>

    {

        static Dictionary<Type, ConstructorInfo> d = new Dictionary<Type, ConstructorInfo>();


        public static T CreateNew(int id)

        {

            Type t = typeof(T);

            if(!d.ContainsKey(t))

                d.Add(t, t.GetConstructor(new Type[] { typeof(int) });

            return (T)d[t].Invoke(new object[] { id });

        }

    }

Not too bad. The only thing I don’t like is that we have to use the ugly “Invoke” syntax and object based parameters. There’s no compile time checking to make sure the right constructor is being called, or has the proper parameters for that matter. However I suspect this is much faster than the Activator.CreateInstance method, so we’re making progress.

However, one of the reasons that I even started examining how to speed up this type of code was a sort of obscure sentence that I read in some Microsoft literature concerning .NET delegates. It said basically that pure delegate invocation in .NET is almost as fast as directly calling the method in the first place. That got me thinking about the creation of new objects in the sense that really we’re just calling a special method, i.e. the constructor. If we could figure out a way to create a persistent delegate that points to our type’s constructor, and call that when we need a new instance, that would surely be as close to the direct method call as possible right? Let’s find out.

 

 

    public static class Proxy<T>

    {

        public delegate T GenericDel<T>(int id);

        static Dictionary<Type, GenericDel<T>> dict = new Dictionary<Type, GenericDel<T>>();

        public static T CreateNew(int id)

        {

            Type t = typeof(T);

            if (!dict.ContainsKey(t))

            {

                var dm = new DynamicMethod("", t, new Type[] { typeof(int) }, t);

                ILGenerator il = dm.GetILGenerator();

                il.Emit(OpCodes.Ldarg_0);

                il.Emit(OpCodes.Newobj, t.GetConstructor(new Type[] { typeof(int) }));

                il.Emit(OpCodes.Ret);

                var d = (GenericDel<T>)dm.CreateDelegate(typeof(GenericDel<T>));

                dict.Add(t, d);

            }

            return dict[t](id);

        }

    }

So we have a few new things here. First is a generic delegate GenericDel<T>. This defines the signature of the method we will call (i.e. our constructor) for any type T. Obviously in a real world situation T would be defined further guaranteeing such a constructor exists. But for this test leaving this off is fine.

Next we have a static dictionary which holds the delegate with it’s key which is a Type object. Now we simply create a DynamicMethod that matches our constructor, emit the IL code that is necessary to call the constructor method successfully (push the first param of the dynamic method onto the caller’s eval stack, create the new object, then return from the method invocation placing the return value on the callee’s eval stack). Then to wrap things up we generate a delegate of this method and add it to the dictionary.

Now notice the return statement for any object of a particular type once the DynamicMethod has been created….it works just like any other method or delegate call, intellisense works, and there is compile time checking for the proper parameterization of the constructor. Plus, since we’re caching the delegate, and not creating it each time a new object is instantiated dynamically, we don’t incur the cost of creating it more than once per application lifecycle.

Now….for the results:

The test for the output shown was done on my laptop, which is a Dell 9400 with an Intel Core Duo T7200 @ 2.00 GHz with 2 Gb of RAM. This particular run was churning through 100 million objects of a class called TestClass (which simply holds an ID value) for each type of invocation we covered in this article. I did not run the Cache version with this test, as it was so slow that 100 million objects would take a very very long time. The fastest two were obviously the Direct invocation and the DynamicMethod & Delegate version, which we covered last.

In this example I took the code out for the DynamicMethod creation to get a true sense of how close delegate invocation is compared to raw calls. The raw calls average around 65 nanoseconds per object instantiation. The DynamicMethod & Delegate version averages just over 76 nanoseconds. Not too shabby at all I’d say!

For those interested, I’ve included the test code I used to generate this demonstration. It is obviously a test only, so please feel free to modify it and test other things that I did not.

Til next time…keep on slangin!

Part II 

---

 Example Project Download