{"id":475,"date":"2017-02-01T13:49:37","date_gmt":"2017-02-01T05:49:37","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/seteplia\/?p=475"},"modified":"2019-06-11T21:01:43","modified_gmt":"2019-06-12T04:01:43","slug":"dissecting-the-new-constraint-in-c-a-perfect-example-of-a-leaky-abstraction","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/premier-developer\/dissecting-the-new-constraint-in-c-a-perfect-example-of-a-leaky-abstraction\/","title":{"rendered":"Dissecting the new() constraint in C#: a perfect example of a leaky abstraction"},"content":{"rendered":"

Most likely you\u2019ve heard about The Law of Leaky Abstractions coined by Joel Spolsky<\/a>. Even if you never heard of it, you definitely faced it in your day-to-day job. The \u201claw\u201d is pretty simple: \u201cAll non-trivial abstractions, to some degree, are leaky\u201d. And this is 100% true. But sometimes even not that complicated abstractions can leak their internal details.<\/p>\n

Let\u2019s consider the following code snippet:<\/p>\n

public class NodeFactory\r\n{\r\n    public static TNode CreateNode<TNode>() \r\n        where TNode : Node, new()\r\n    {\r\n        return new TNode();\r\n    }\r\n}<\/pre>\n
Do you see any issues with it? Will it pass a thorough code review? Of course, you need to know the context. For instance, you need to know what the TNode<\/b> types are, whether the constructor of those types can throw exceptions and whether the method can be called on a hot path of an app.<\/p>\n
But first of all, you need to know what the compiler and the runtime will do with a method like this.<\/p>\n
Once a user calls a method CreateNode<\/b>, the C# compiler checks that a given type has a default constructor and if this is the case the compiler will emit a call to it. Right? Not exactly. The compiler doesn\u2019t know upfront what constructor to call, so it delegates all the job to a helper method \u2013 Activator.CreateInstance<T><\/b> (*).<\/p>\n
(*) This statement is not 100% correct. Different C# compilers emit different code for new T()<\/b>. The C# compiler starting from VS2015 emits a call to the Activator.CreateInstance()<\/b>, but older versions are \u201csmarter\u201d: they return default(T)<\/b> for value types and calls the Activator.CreateInstance()<\/b> only for reference types.<\/p>\n
Ok, and what\u2019s wrong with the Activator<\/b>? Nothing, if you know how it\u2019s implemented.<\/p>\n
Implementation details of the Activator.CreateInstance<\/h4>\n
Non-generic version of the Activator.CreateInstance(Type)<\/b> was first introduced in the .NET Framework 1.0 and was based on reflection. The method checks for a default constructor of a given type and calls it to construct an instance. We can even implement a very na\u00efve version of this method ourselves:<\/p>\n
{\r\n    public static T CreateInstance<T>() where T : new()\r\n    {\r\n        return (T) CreateInstance(typeof(T));\r\n    }\r\n\r\n    public static object CreateInstance(Type type)\r\n    {\r\n        var constructor = type.GetConstructor(new Type[0]);\r\n        if (constructor == null && !type.IsValueType)\r\n        {\r\n            throw new NotSupportedException($\"Type '{type.FullName}' doesn't have a parameterless constructor\");\r\n        }\r\n\r\n        var emptyInstance = FormatterServices.GetUninitializedObject(type);\r\n            \r\n        return constructor?.Invoke(emptyInstance, new object[0]) ?? emptyInstance;\r\n    }\r\n}<\/pre>\n
As we\u2019ll see shortly an actual implementation of Activator.CreateInstance<\/b> is a bit more complicated and relies on some internal CLR methods for creating an uninitialized instance. But the idea is the same: get a ConstructorInfo<\/b>, create uninitialized instance and then call the constructor to initialized it, similar to the placement new<\/a> concept in C++.<\/p>\n
But the generic version \u201cknows\u201d the type being created at compile time so the implementation could be way more efficient, right? Nope. Generic version is just a fa\u00e7ade that gets the type from its generic argument and calls the old method \u2013 reflection-based Activator.CreateInstance(Type)<\/b>.<\/p>\n
You may wander: \u201cOk, for new T()<\/b> the C# compiler calls Activator.CreateInstance<T>()<\/b> that calls Activator.CreateInstance(Type)<\/b> that uses reflection to do its job. Is it a big deal?\u201d Yes, it is!<\/p>\n
Concern #1. Performance<\/h4>\n
Using reflection to create a frequently instantiated type can substantially affect the performance of your application. Currently I work on build system and one of the components is responsible for parsing build specification files. The first implementation of the parser was used a factory method that created every node using new TNode()<\/b> as shown above. The very first profiling session showed a sizable impact of the factory on the end-to-end performance. Just by switching to a more expression-based implementation of the node factory we gained 10% performance improvements for one of our end-to-end scenarios.<\/p>\n
To be more specific, let\u2019s compare different ways of creating a Node<\/b> instance: explicit construction, using Func<Node><\/b>, Activator.CreateInstance<\/b> and a custom factory based on the new()<\/b> constraint.<\/p>\n
public static T Create<T>() where T : new() => new T();\r\npublic static Func<Node> NodeFactory => () => new Node();\r\n\r\n\r\n\/\/ Benchmark 1: ActivatorCreateInstace\r\nvar node1 = System.Activator.CreateInstance<Node>();\r\n\/\/ Benchmark 2: FactoryWithNewConstraint\r\nvar node2 = Create<Node>();\r\n\/\/ Benchmark 3: ConstructorCall\r\nvar node3 = new Node();\r\n\/\/ Benchmark 4: FuncBasedFactory\r\nvar node4 = NodeFactory();<\/pre>\n
Here are the perf numbers obtained using BenchmarkDotNet<\/a>:<\/p>\n
                         Method |        Mean |    StdDev |  Gen 0 |\r\n------------------------------- |------------ |---------- |------- |\r\n        ActivatorCreateInstance |  98.6628 ns | 3.0845 ns |      - |\r\n FactoryMethodWithNewConstraint | 103.0030 ns | 4.2670 ns |      - |\r\n                ConstructorCall |   2.4361 ns | 0.0430 ns | 0.0036 |\r\n               FuncBasedFactory |   6.8369 ns | 0.0436 ns | 0.0034 |<\/pre>\n
As we can see, the difference is pretty drastic: a factory method based on the new()<\/b> constraint is 15 times slower than a delegate-based solution and 50 times slower than manual construction. But performance is not the only concern.<\/p>\n
Correctness<\/h4>\n
Reflection-based method invocation means that any exception thrown from the method will be wrapped in a TargetInvocationException<\/b>:<\/p>\n
class Node\r\n{\r\n    public Node()\r\n    {\r\n        throw new InvalidOperationException();\r\n    }\r\n}\r\n\r\npublic static T Create<T>() where T : new() => new T();\r\n\r\n\r\ntry\r\n{\r\n    var node = Create<Node>();\r\n    Console.WriteLine(\"Node was create successfully\");\r\n}\r\ncatch (InvalidOperationException)\r\n{\r\n    \/\/ Handling the error!\r\n    Console.WriteLine(\"Failed to create a node!\");\r\n}<\/pre>\n
Is it obvious for everyone that the code shown above is incorrect? Reflection-based object construction \u201cleaks\u201d through the generics implementation<\/b>. And now every developer needs to know how<\/i> new T()<\/b>is implemented and the consequences it has in terms of exception handling: every exception thrown from the constructor will be wrapped in a TargetInvocationException<\/b>!<\/p>\n
You may fix the issue if you know that the type\u2019s constructor may throw an exception. Starting from .NET 4.5 you can use ExceptionDispatchInfo<\/b> class to rethrow an arbitrary exception object (an inner exception in this case) without altering the exception\u2019s stack trace:<\/p>\n
public static T Create<T>() where T : new()\r\n{\r\n    try\r\n    {\r\n        return new T();\r\n    }\r\n    catch (TargetInvocationException e)\r\n    {\r\n        var edi = ExceptionDispatchInfo.Capture(e.InnerException);\r\n        edi.Throw();\r\n        \/\/ Required to avoid compiler error regarding unreachable code\r\n        throw;\r\n    }\r\n}<\/pre>\n
This code solves one issue with Activator.CreateInstance<\/b>, but as we\u2019ll see in a moment, there are better solutions that fix correctness as well as performance issues.<\/p>\n
Correctness (2)<\/h4>\n
Activator.CreateInstance<\/b> is implemented in a more complicated way than I mentioned before. Actually, it has a cache that holds constructor information for the last 16 instantiated types . This means that the user won\u2019t pay the cost of getting the constructor info via reflection all the time, although it will pay the cost of a slow reflection-based constructor invocation.<\/p>\n
A more accurate description of the algorithm used by Activator.CreateInstance<\/b> is as following:<\/p>\n
    \n
  1. Create a raw instance using RuntimeTypeHandle<\/a>.Allocate<\/a>(this<\/a>)<\/li>\n
  2. Get the ConstructorInfo<\/b> for the given type\u2019s parameterless constructor\n
      \n
    1. If the constructor information is already in the cache, get it from there<\/li>\n
    2. If the constructor information is not in the cache, get a ConstructorInfo<\/b> via reflection and put it into the cache<\/li>\n<\/ol>\n<\/li>\n
    3. Call the constructor on the newly created instance and return a fully constructed instance to the caller<\/li>\n<\/ol>\n
      But unfortunately, this optimization has an issue (reproducible in .NET 4.0 \u2013 4.6.2): the optimization doesn\u2019t handle structs with a parameterless constructor properly. Current C# compiler doesn\u2019t support custom default constructors for structs. But the CLR and some other languages do: you may create a struct with a default constructor using C++\/CLI or IL directly. Moreover, this feature was added to C# 6, but was removed<\/a> from the language 3 months before the official release. And the reason is this bug<\/a> in Activator.CreateInstance<\/b>. Today there is a hot discussion<\/a> at github about this feature, and it seems that even the language authors can\u2019t agree on whether default constructors on structs is a good thing or not.<\/p>\n
      The issue is related to a caching logic in Activator.CreateInstance<\/b>: if it gets the constructor information from the cache it doesn\u2019t call the constructor for structs assuming, apparently, that they don\u2019t exist (see InitializeCacheEntry<\/a> method). And this means that if you have a struct with a default constructor, and you create an instance of that type multiple times, the constructor will only be called for the first instance.<\/p>\n
      We can\u2019t easily fix the issues in Activator.CreateInstance<\/b> and we definitely can\u2019t change the existing behavior of new T()<\/b> without breaking the world. But we can avoid using it and create our own generic factory that won\u2019t suffer from the aforementioned issues.<\/p>\n
      Solution #1: using expression trees<\/h4>\n
      Expression trees<\/a> are a good tool for lightweight code generation. In our case, we can use an expression tree that creates a new instance of type T<\/b>. And then we can compile it to a delegate to avoid performance penalty.<\/p>\n
      Lambda-expressions are special in the C# language because they\u2019re convertible by the compiler to a delegate (DelegateType)<\/b> or to an expression (Expression<DelegateType><\/b>). The compiler can convert an arbitrary expression to a delegate but only a limited set of language constructs can be converted to an expression. In our case the expression is very simple, so the compiler can cope with it:<\/p>\n
      public static class FastActivator\r\n{\r\n    public static T CreateInstance<T>() where T : new()\r\n    {\r\n        return FastActivatorImpl<T>.NewFunction();\r\n    }\r\n\r\n    private static class FastActivatorImpl<T> where T : new()\r\n    {\r\n        \/\/ Compiler translates 'new T()' into Expression.New()\r\n        private static readonly Expression<Func<T>> NewExpression = () => new T();\r\n\r\n        \/\/ Compiling expression into the delegate\r\n        public static readonly Func<T> NewFunction = NewExpression.Compile();\r\n    }\r\n}<\/pre>\n
      FastActivator.CreateInstance<\/b> is conceptually similar to Activator.CreateInstance<\/b> but it lacks two main issues: it doesn\u2019t suffer from the exception-wrapping problem and it doesn\u2019t rely on reflection during the execution (it does rely on the reflection during expression construction, but this happens only once).<\/p>\n
      Let\u2019s compare different solutions and see what we get:<\/p>\n
      \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Method |\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Mean |\u00a0\u00a0\u00a0 StdDev |\u00a0 Gen 0 |\r\n---------------------------- |----------- |---------- |------- |\r\n\u00a0\u00a0\u00a0\u00a0 ActivatorCreateInstance | 94.6173 ns | 0.5036 ns |\u00a0\u00a0\u00a0\u00a0\u00a0 - |\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 FuncBasedFactory |\u00a0 6.5049 ns | 0.0551 ns | 0.0034 |\r\n FastActivatorCreateInstance | 22.2258 ns | 0.2240 ns | 0.0020 |<\/pre>\n
      FastActivator<\/b> is almost 5 times faster than the default one, but still 3.5 times slower than the func-based factory. I\u2019ve intentionally removed the other cases we saw at the beginning; func-based solution is our base line, because any custom solution can\u2019t beat an explicit constructor call for a known type.<\/p>\n
      The question is, why is the compiled delegate way slower than a manually-written delegate? Expression.Compile<\/a> creates a DynamicMethod<\/a> and associates it with an anonymous assembly to run it in a sandboxed environment. This makes it safe for a dynamic method to be emitted and executed by partially trusted code but adds some run-time overhead.<\/p>\n
      The overhead can be removed by using a constructor<\/a> of DynamicMethod<\/b> which associates it with a specific module. Unfortunately, Expression.Compile<\/b> doesn\u2019t allow us to customize the creation of a dynamic method and the only other option is to use Expression.CompileToMethod<\/a>. CompileToMethod<\/b> compiles the expression into a given MethodBuilder<\/a> instance. But this won\u2019t work for our scenario because we can\u2019t create a method via MethodBuilder<\/b> that has access to internal\/private members of different assemblies. And this will restrict our factory to public types only.<\/p>\n
      Instead of relying on Expression.Compile<\/b> we can \u201ccompile\u201d our simple factory manually:<\/p>\n
      public static class DynamicModuleLambdaCompiler\r\n{\r\n    public static Func<T> GenerateFactory<T>() where T:new()\r\n    {\r\n        Expression<Func<T>> expr = () => new T();\r\n        NewExpression newExpr = (NewExpression)expr.Body;\r\n\r\n        var method = new DynamicMethod(\r\n            name: \"lambda\", \r\n            returnType: newExpr.Type,\r\n            parameterTypes: new Type[0],\r\n            m: typeof(DynamicModuleLambdaCompiler).Module,\r\n            skipVisibility: true);\r\n\r\n        ILGenerator ilGen = method.GetILGenerator();\r\n        \/\/ Constructor for value types could be null\r\n        if (newExpr.Constructor != null)\r\n        {\r\n            ilGen.Emit(OpCodes.Newobj, newExpr.Constructor);\r\n        }\r\n        else\r\n        {\r\n            LocalBuilder temp = ilGen.DeclareLocal(newExpr.Type);\r\n            ilGen.Emit(OpCodes.Ldloca, temp);\r\n            ilGen.Emit(OpCodes.Initobj, newExpr.Type);\r\n            ilGen.Emit(OpCodes.Ldloc, temp);\r\n        }\r\n            \r\n        ilGen.Emit(OpCodes.Ret);\r\n\r\n        return (Func<T>)method.CreateDelegate(typeof(Func<T>));\r\n    }\r\n}<\/pre>\n
      The GenerateFactory<\/b> method creates a DynamicMethod<\/b> instance and associates that method with a given module. This immediately gives the method access to all internal members of the current assembly. But we specify skipVisibility<\/b> as well, because the factory method should be able to create internal\/private types declared in other assemblies as well. The name \u2018lambda\u2019 is never used and would be visible only during debugging.<\/p>\n
      This method creates an expression tree to get the constructor information even though we can get it manually. Note that the method checks newExpr.ConstructorInfo<\/b> and uses different logic if the constructor is missing (i.e. for value types without a default constructor defined).<\/p>\n
      With the new helper method, FastActivator<\/b> will be implemented in the following way:<\/p>\n
      public static class FastActivator\r\n{\r\n    public static T CreateInstance<T>() where T : new()\r\n    {\r\n        return FastActivatorImpl<T>.Create();\r\n    }\r\n\r\n    private static class FastActivatorImpl<T> where T : new()\r\n    {\r\n        public static readonly Func<T> Create =\r\n            DynamicModuleLambdaCompiler.GenerateFactory<T>();\r\n    }\r\n}<\/pre>\n
      Let\u2019s compare the new implementation (FastActivatorCreateInstance<\/b>) with the expression-based one (CompiledExpression<\/b>):<\/p>\n
      \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Method |\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Mean |\u00a0\u00a0\u00a0 StdDev |\u00a0 Gen 0 |\r\n---------------------------- |----------- |---------- |------- |\r\n\u00a0\u00a0\u00a0\u00a0 ActivatorCreateInstance | 93.8858 ns | 1.2702 ns |\u00a0\u00a0\u00a0\u00a0\u00a0 - |\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 FuncBasedFactory |\u00a0 6.4719 ns | 0.0640 ns | 0.0033 |\r\n FastActivatorCreateInstance | 11.6035 ns | 0.0774 ns | 0.0030 |\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 CompiledExpression | 22.7874 ns | 0.1509 ns | 0.0021 |<\/pre>\n
      As we can see, the new version of the fast activator is two times faster than the old one, but still two times slower than the func-based factory. Let\u2019s explore, why.<\/p>\n
      The reason is in implementation of the generics in the CLR. A generic method that calls a method from a generic type will never be inlined, so we suffer the overhead of an additional method call. But the more important thing is subtler. If the generic is instantiated with a value type the CLR has no other options except to generate a separate type for it. This means that a List<int><\/b> and a List<double><\/b> are completely independent from the CLR perspective. However, this is not the case with reference types. Two generic instantiations like List<string> <\/b>and List<object><\/b> share the same EEClass, which allows the CLR to reuse the code between different instantiations and avoid code bloating. But this optimization trades speed for memory.<\/p>\n
      When you have one generic type (or method) that calls another generic type (or method) the CLR needs to make sure that actual types are compatible at runtime (**). To make sure that this is the case the CLR will make a few look-ups that affect the performance in the previous example and make our FastActivator<\/b> slower than the delegate like () => new Node()<\/b>.<\/p>\n
      (**) The CLR implementation of generics is a very complicated topic and it\u2019s definitely out of scope of this blogpost. If you want to understand the design of generics and the complexity of the problem better, I recommend to read an amazing article written by the author of the generics in .NET – Don Syme – Design and Implementation of Generics for the .NET Common Language Runtime<\/a>. If you want to understand the current state of affairs, please see Pro .NET Performance<\/a> or a very good article by Alexandr Nikitin, .NET Generics under the hood<\/a>.<\/p>\n
      To prove this assumption let\u2019s use the same factory on a value type Node<\/b>:<\/p>\n
       <\/p>\n
      \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Method |\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Mean |\u00a0\u00a0\u00a0 StdDev |\u00a0 Gen 0 | Allocated |\r\n---------------------------- |----------- |---------- |------- |---------- |\r\n\u00a0\u00a0\u00a0\u00a0 ActivatorCreateInstance | 86.4298 ns | 2.5527 ns | 0.0005 |\u00a0\u00a0\u00a0\u00a0\u00a0 12 B |\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 FuncBasedFactory |\u00a0 4.7406 ns | 0.0254 ns |\u00a0\u00a0\u00a0\u00a0\u00a0 - |\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 0 B |\r\n FastActivatorCreateInstance |\u00a0 4.3134 ns | 0.0159 ns |\u00a0\u00a0\u00a0\u00a0\u00a0 - |\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 0 B |\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 CompiledExpression |\u00a0 3.1534 ns | 0.0210 ns |\u00a0\u00a0\u00a0\u00a0\u00a0 - |\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 0 B |<\/pre>\n
       <\/p>\n
      As we can see, there is no performance impact of the current solution when structs are involved.<\/p>\n
      To solve the issue with reference types we can avoid additional level of indirection and move the nested FastActivatorImpl<T><\/b> out from the fa\u00e7ade FastActivator<\/b> type and use it directly:<\/p>\n
      public static class FastActivator<T> where T : new()\r\n{\r\n    \/\/\/ <summary>\r\n    \/\/\/ Extremely fast generic factory method that returns an instance\r\n    \/\/\/ of the type <typeparam name=\"T\"\/>.\r\n    \/\/\/ <\/summary>\r\n    public static readonly Func<T> Create =\r\n        DynamicModuleLambdaCompiler.GenerateFactory<T>();\r\n}<\/pre>\n
      And here are the last results when the FastActivator<T><\/b> is introduced and used directly:<\/p>\n
      \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Method |\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Mean |\u00a0\u00a0\u00a0 StdDev |\u00a0 Gen 0 |\r\n------------------------ |----------- |---------- |------- |\r\n ActivatorCreateInstance | 95.0161 ns | 1.0861 ns | 0.0005 |\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 FuncBasedFactory |\u00a0 6.5741 ns | 0.0608 ns | 0.0034 |\r\n\u00a0 FastActivator_T_Create<\/strong> |\u00a0 5.1715 ns | 0.0466 ns | 0.0034 |<\/pre>\n
      As you can see we\u2019ve achieved the goal and created a generic factory method with the same performance characteristic as a plain delegate that instantiates a specific type!<\/p>\n
      Application-specific fix for the Activator.CreateInstance issue<\/h4>\n
      The C# compiler uses \u201cduck typing\u201d for many language constructs. For example, LINQ syntax is pattern based: if the compiler is able to find Select<\/b>, Where<\/b> and other methods for a given variable (via extension methods or as instance methods) it will be able to compile queries using a query comprehension syntax<\/a>.<\/p>\n
      The same is true for some other language features, like the collection initialization syntax, async\/await, foreach loop and others. But not everyone knows that there is a large list of \u201cwell known members\u201d<\/a> that the user may potentially provide to change the runtime behavior. And one of such well-known members is Activator.CreateInstance<T><\/b>.<\/p>\n
      This means that if the C# compiler is able to find another System.Activator<\/b> type with a generic CreateInstance<\/b> method then the given method will be used instead of the method from mscorlib<\/b>. The following behavior is undocumented and I would not recommend using it in a production environment without clear evidence from a profiler.<\/b> And even if a profiler shows some benefit , I would prefer using FastActivator<\/b> explicitly instead on relying on this hack.<\/p>\n
      namespace System\r\n{\r\n    \/\/\/ <summary>\r\n    \/\/\/ Dirty hack that allows using a fast implementation\r\n    \/\/\/ of the activator.\r\n    \/\/\/ <\/summary>\r\n    public static class Activator\r\n    {\r\n        public static T CreateInstance<T>() where T : new()\r\n        {\r\n#if DEBUG\r\n        Console.WriteLine(\"Fast Activator was called\");\r\n#endif\r\n            return ActivatorImpl<T>.Create();\r\n        }\r\n\r\n        private static class ActivatorImpl<T> where T : new()\r\n        {\r\n            public static readonly Func<T> Create =\r\n                DynamicModuleLambdaCompiler.GenerateFactory<T>();\r\n        }\r\n    }\r\n}<\/pre>\n
      Now, all methods that call new T() <\/b>to create an instance of a type, will use our custom implementation instead of relying on the default one.<\/p>\n
      Conclusion<\/h4>\n
      This is a fairly long post, but we managed to cover many interesting details.<\/p>\n
        \n
      • The new()<\/b> constraint in the C# language is extremely leaky: in order to use it correctly and efficiently the developer should understand the implementation details of the compiler and the BCL.<\/li>\n
      • We\u2019ve figured out that the C# compiler calls Activator.CreateInstance<T><\/b> for creating an instance of a generic argument with a new()<\/b> constraint (but remember, this is true only for C# 6+ compilers and the older versions emit the call only for reference types).<\/li>\n
      • We\u2019ve discovered the implications of the Activator.CreateInstance<\/b> from a developer\u2019s point of view in terms of correctness and performance.<\/li>\n
      • We\u2019ve come up with a few alternatives, starting with a very simple one that \u201cunwraps\u201d TargetInvocationException<\/b>, to a fairly sophisticated solution based on code generation.<\/li>\n
      • We\u2019ve discussed a few interesting aspects of the generics implementation in the CLR and their impact on the performance (very minor, and likely negligible in the vast majority of cases).<\/li>\n
      • And finally, we\u2019ve come up with a solution that can solve aforementioned issues with the new()<\/b> constrained by using the custom System.Activator.CreateInstance<T><\/b> implementation.<\/li>\n<\/ul>\n
        And as a final conclusion I won\u2019t suggest that anyone removes all calls to new T()<\/b> in their codebase or define their own System.Activator<\/b> class. You need to profile your application and make the decision only based on real evidence.<\/p>\n
        But to avoid shooting yourself in the foot, you need to know what the compiler and the runtime do for new T()<\/b> and other widely used language constructs and what the implications are from correctness and performance perspectives.<\/p>\n","protected":false},"excerpt":{"rendered":"
        Most likely you\u2019ve heard about The Law of Leaky Abstractions coined by Joel Spolsky. Even if you never heard of it, you definitely faced it in your day-to-day job. The \u201claw\u201d is pretty simple: \u201cAll non-trivial abstractions, to some degree, are leaky\u201d. And this is 100% true. But sometimes even not that complicated abstractions can […]<\/p>\n","protected":false},"author":4004,"featured_media":37840,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[6699],"tags":[6695],"class_list":["post-475","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-c","tag-seteplia"],"acf":[],"blog_post_summary":"
        Most likely you\u2019ve heard about The Law of Leaky Abstractions coined by Joel Spolsky. Even if you never heard of it, you definitely faced it in your day-to-day job. The \u201claw\u201d is pretty simple: \u201cAll non-trivial abstractions, to some degree, are leaky\u201d. And this is 100% true. But sometimes even not that complicated abstractions can […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/posts\/475","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/users\/4004"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/comments?post=475"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/posts\/475\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/media\/37840"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/media?parent=475"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/categories?post=475"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/premier-developer\/wp-json\/wp\/v2\/tags?post=475"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}