Разница между Activator.CreateInstance() и typeof (T) .InvokeMember() с BindingFlags.CreateInstance

Question

Простите меня, если этот вопрос уже задан и дан ответ.

Учитывая класс типа T, в чем разница между следующим?

T myObj = Activator.CreateInstance<T>(); 

T myObj = typeof(T).InvokeMember(null, BindingFlags.CreateInstance, null, null, null); 

Является ли одно решение предпочтительным по сравнению с другим?

Answer 1

Декомпиляция RuntimeType.InvokeMember дает этот фрагмент:

if ((bindingFlags & BindingFlags.CreateInstance) != BindingFlags.Default) 
{ 
    if (((bindingFlags & BindingFlags.CreateInstance) != BindingFlags.Default) && ((bindingFlags & (BindingFlags.SetProperty | BindingFlags.GetProperty | BindingFlags.SetField | BindingFlags.GetField | BindingFlags.InvokeMethod)) != BindingFlags.Default)) 
    { 
     throw new ArgumentException(Environment.GetResourceString("Arg_CreatInstAccess"), "bindingFlags"); 
    } 
    return Activator.CreateInstance(this, bindingFlags, binder, providedArgs, culture); 
} 

Другими словами, InvokeMember с теми, BindingFlags называет Activator.CreateInstance. Он проходит через несколько уровней вызовов (проверяя привязки, проверяя аргументы), прежде чем перейти к делу. Activator.CreateInstance<T> гораздо более емким:

public static T CreateInstance<T>() 
{ 
    bool bNeedSecurityCheck = true; 
    bool canBeCached = false; 
    RuntimeMethodHandle emptyHandle = RuntimeMethodHandle.EmptyHandle; 
    return (T) RuntimeTypeHandle.CreateInstance(typeof(T) as RuntimeType, true, true, ref canBeCached, ref emptyHandle, ref bNeedSecurityCheck); 
} 

EDITED Вы можете ожидать, что последний будет быстрее, но метод, называемый RuntimeType.CreateInstanceSlow также призывает RuntimeTypeHandle.CreateInstance сделать работу; он используется как резерв, если запись кэша активатора для конструктора не найдена. Я бы сделал некоторые тесты производительности, если вы ищете быстрое решение этих двух.