Does System.Activator.CreateInstance(T) have performance issues big enough to discourage us from using it casually?

Question

Does System.Activator.CreateInstance(T) method have performance issues (since I'm suspecting it uses reflection) big enough to discourage us from using it casually?

Dialectic

The only answer will be "depends". Yes, it does use reflection, and yes, use it if you need it! – Hawley

It might help to know, that "new T()" in templates uses Activator.CreateInstance<T>() behind the scenes also. – Sacerdotalism

@Lasse V. Karlsen, @Pacerier: sorry, too much C++ lately, I ment "when using Generics" (see Remarks) – Sacerdotalism

@Christian do you mean that when we specify {new} as a type constraint in generics and we call new T it actually uses System.Activator? – Dialectic

@Pacerier: Yes, that is what he is saying, and it is backed by the MSDN page he links to (Remarks in his comment.) – Incommunicable

Related: #6708959 – Sigismundo

Answer 1

As always, the only correct way to answer a question about performance is to actually measure the code.

Here's a sample LINQPad program that tests:

• Activator.CreateInstance
• new T()
• calling a delegate that calls new T()

As always, take the performance program with a grain of salt, there might be bugs here that skews the results.

The output (timing values are in milliseconds):

Test1 - Activator.CreateInstance<T>() 
12342 

Test2 - new T() 
1119 

Test3 - Delegate 
1530 

Baseline 
578 

Note that the above timings are for 100.000.000 (100 million) constructions of the object. The overhead might not be a real problem for your program.

Cautionary conclusion would be that Activator.CreateInstance<T> is taking roughly 11 times as much time to do the same job as a new T() does, and a delegate takes roughly 1.5 times as much. Note that the constructor here does nothing, so I only tried to measure the overhead of the different methods.

Edit: I added a baseline call that does not construct the object, but does the rest of the things, and timed that as well. With that as a baseline, it looks like a delegate takes 75% more time than a simple new(), and the Activator.CreateInstance takes around 1100% more.

However, this is micro-optimization. If you really need to do this, and eek out the last ounce of performance of some time-critical code, I would either hand-code a delegate to use instead, or if that is not possible, ie. you need to provide the type at runtime, I would use Reflection.Emit to produce that delegate dynamically.

In any case, and here is my real answer:

If you have a performance problem, first measure to see where your bottleneck is. Yes, the above timings might indicate that Activator.CreateInstance has more overhead than a dynamically built delegate, but there might be much bigger fish to fry in your codebase before you get (or even have to get) to this level of optimization.

And just to make sure I actually answer your concrete question: No, I would not discourage use of Activator.CreateInstance. You should be aware that it uses reflection so that you know that if this tops your profiling lists of bottlenecks, then you might be able to do something about it, but the fact that it uses reflection does not mean it is the bottleneck.

The program:

void Main()
{
    const int IterationCount = 100000000;

    // warmup
    Test1();
    Test2();
    Test3();
    Test4();

    // profile Activator.CreateInstance<T>()
    Stopwatch sw = Stopwatch.StartNew();
    for (int index = 0; index < IterationCount; index++)
        Test1();
    sw.Stop();
    sw.ElapsedMilliseconds.Dump("Test1 - Activator.CreateInstance<T>()");

    // profile new T()
    sw.Restart();
    for (int index = 0; index < IterationCount; index++)
        Test2();
    sw.Stop();
    sw.ElapsedMilliseconds.Dump("Test2 - new T()");

    // profile Delegate
    sw.Restart();
    for (int index = 0; index < IterationCount; index++)
        Test3();
    sw.Stop();
    sw.ElapsedMilliseconds.Dump("Test3 - Delegate");

    // profile Baseline
    sw.Restart();
    for (int index = 0; index < IterationCount; index++)
        Test4();
    sw.Stop();
    sw.ElapsedMilliseconds.Dump("Baseline");
}

public void Test1()
{
    var obj = Activator.CreateInstance<TestClass>();
    GC.KeepAlive(obj);
}

public void Test2()
{
    var obj = new TestClass();
    GC.KeepAlive(obj);
}

static Func<TestClass> Create = delegate
{
    return new TestClass();
};

public void Test3()
{
    var obj = Create();
    GC.KeepAlive(obj);
}

TestClass x = new TestClass();
public void Test4()
{
    GC.KeepAlive(x);
}

public class TestClass
{
}

Incommunicable

Interesting to note that T Create<T>() where T: new() { return new T()} is as slow as Activator.CreateInstance so there is a huge penalty when instantiating generic type classes :( – Soilasoilage

Well, I wouldn't say huge, as it is relative to other costs. It is more costly than a simple new(), but I doubt it is a problem in any but the most extreme cases. – Incommunicable

@Arunas: I included some generics tests in my answer below, but found that generics using Activator.CreateInstance with a binding to allow an internal constructor to be called is over 6x slower! Do you have any idea why that is? – Angloamerican

Answer 2

Here's a sample C# .NET 4.0 program that tests:

• Activator.CreateInstance
• new T()
• calling a delegate that calls new T()
• generic new()
• Activator.CreateInstance using a generic
• Activator.CreateInstance using a generic and non-default bindings (e.g. to call internal constructor)

The output (timing values are in milliseconds from a 2014 beefy machine with x86 release build):

Test1 - Activator.CreateInstance<T>(): 8542
Test2 - new T() 1082
Test3 - Delegate 1214
Test4 - Generic new() 8759
Test5 - Generic activator 9166
Test6 - Generic activator with bindings 60772
Baseline 322

This is adopted from Lasse V. Karlsen's answer, but importantly includes generics. Note that specifying bindings slows down Activator using generics by more than a factor of 6!

using System;
using System.Reflection;
using System.Diagnostics;

namespace ConsoleApplication1
{
    public class TestClass
    {
    }

    class Program
    {
        static void Main(string[] args)
        {
            const int IterationCount = 100000000;

            // warmup
            Test1();
            Test2();
            Test3();
            Test4<TestClass>();
            Test5<TestClass>();
            Test6<TestClass>();

            // profile Activator.CreateInstance<T>()
            Stopwatch sw = Stopwatch.StartNew();
            for (int index = 0; index < IterationCount; index++)
                Test1();
            sw.Stop();
            Console.WriteLine("Test1 - Activator.CreateInstance<T>(): {0}", sw.ElapsedMilliseconds);

            // profile new T()
            sw.Restart();
            for (int index = 0; index < IterationCount; index++)
                Test2();
            sw.Stop();
            Console.WriteLine("Test2 - new T() {0}", sw.ElapsedMilliseconds);

            // profile Delegate
            sw.Restart();
            for (int index = 0; index < IterationCount; index++)
                Test3();
            sw.Stop();
            Console.WriteLine("Test3 - Delegate {0}", sw.ElapsedMilliseconds);

            // profile generic new()
            sw.Restart();
            for (int index = 0; index < IterationCount; index++)
                Test4<TestClass>();
            sw.Stop();
            Console.WriteLine("Test4 - Generic new() {0}", sw.ElapsedMilliseconds);

            // generic Activator without bindings
            sw.Restart();
            for (int index = 0; index < IterationCount; index++)
                Test5<TestClass>();
            sw.Stop();
            Console.WriteLine("Test5 - Generic activator {0}", sw.ElapsedMilliseconds);

            // profile Activator with bindings
            sw.Restart();
            for (int index = 0; index < IterationCount; index++)
                Test6<TestClass>();
            sw.Stop();
            Console.WriteLine("Test6 - Generic activator with bindings {0}", sw.ElapsedMilliseconds);


            // profile Baseline
            sw.Restart();
            for (int index = 0; index < IterationCount; index++)
                TestBaseline();
            sw.Stop();
            Console.WriteLine("Baseline {0}", sw.ElapsedMilliseconds);
        }

        public static void Test1()
        {
            var obj = Activator.CreateInstance<TestClass>();
            GC.KeepAlive(obj);
        }

        public static void Test2()
        {
            var obj = new TestClass();
            GC.KeepAlive(obj);
        }

        static Func<TestClass> Create = delegate
        {
            return new TestClass();
        };

        public static void Test3()
        {
            var obj = Create();
            GC.KeepAlive(obj);
        }

        public static void Test4<T>() where T : new()
        {
            var obj = new T();
            GC.KeepAlive(obj);
        }

        public static void Test5<T>()
        {
            var obj = ((T)Activator.CreateInstance(typeof(T)));
            GC.KeepAlive(obj);
        }

        private const BindingFlags anyAccess = BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic;

        public static void Test6<T>()
        {
            var obj = ((T)Activator.CreateInstance(typeof(T), anyAccess, null, null, null));
            GC.KeepAlive(obj);
        }

        static TestClass x = new TestClass();
        public static void TestBaseline()
        {
            GC.KeepAlive(x);
        }
    }
}

Angloamerican

While this is mostly just a regurgitation of Lasse V. Karlsen's excellent answer, I thought C# would be more relevant for most people, and including the generic new() comparison was very important. – Angloamerican

Does anyone know why the bindings test is 6x slower and how to speed it up? – Angloamerican

You could probably create a Expression tree to create a method with the arguments. This clearly if the type and number of the arguments is "fixed" – Ebeneser

Answer 3

It depends on your use case. If you need very high performance and are creating many objects then using Activator.CreateInstance may be a problem.

But in most cases it will be fast enough and it is a very powerful method of creating objects.

In fact, most IoC Containers/Service locators/whatever you call them use this method to create an object of the type you are requesting.

If you are worried that the performance is not good enough then you should do a profiling of your application and measure if you have a bottleneck and where it is. My guess is that the call to Activator.CreateInstance will not be your problem.

Shotgun

Answer 4

Yes there is a performance difference between calling

(MyClass)Activator.CreateInstance(typeof(MyClass));

and

new MyClass();

where the latter is faster. But determining whether the speed drop is big enough is up to your domain. In 90% of the case it's not an issue. Also note that for value types, Activator.CreateInstance is again slower because of the unboxing involved.

But here is the catch: For generic types, they are similar. new T() internally calls Activator.CreateInstance<T>() which in turn calls RuntimeType.CreateInstanceDefaultCtor(...). So if you're having a generic method to create new instance of T, then it shouldn't matter, though having a new() constraint and calling new T() is much more readable. Here's relevant link on the subject by Jon Skeet.

Sigismundo

Answer 5

Yes, actually it has performance issue (in comparison with new()) since it uses Reflection and static compiler checks specially when you pass parameters to it (sending parameters to class's constructor) instead of using default constructor (like below)

//Too bad!!!
T someResult = (T)Activator.CreateInstance(
 typeof(T),   
 //parameter
 new object[] {id}
);

To use it or not in my opinion depends on two things:

First your application type and of course it's scale (and it's typical traffic)

And second (and more importantly) how and where you use Activator.CreateInstance method, for instance if you use it on every request with one or more constructor parameters (as I mentioned using with constructor parameters is almost one tenth slower than using without parameters (default constructor)), your application's performance deteriorate almost in a significant amount but for another instance if you use it once (on application_start for example) and with no constructor parameter it almost acts like new keyword

here is a detailed benchmark comparison between new(),Activator.CreateInstance and Type.GetInstance()

new vs Func vs Activator.CreateInstance()

Humidify