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?
相关问题
- Generic Generics in Managed C++
- How to Debug/Register a Permanent WMI Event Which
- 'System.Threading.ThreadAbortException' in
- Faster loop: foreach vs some (performance of jsper
- Bulk update SQL Server C#
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.Here's a sample C# .NET 4.0 program that tests:
The output (timing values are in milliseconds from a 2014 beefy machine with x86 release build):
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!
Yes, actually it has performance issue (in comparison with
new()
) since it usesReflection
and static compiler checks specially when you pass parameters to it (sending parameters to class's constructor) instead of using default constructor (like below)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 likenew
keywordhere is a detailed benchmark comparison between
new()
,Activator.CreateInstance
andType.GetInstance()
new vs Func vs Activator.CreateInstance()
Yes there is a performance difference between calling
and
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 callsActivator.CreateInstance<T>()
which in turn calls RuntimeType.CreateInstanceDefaultCtor(...). So if you're having a generic method to create new instance ofT
, then it shouldn't matter, though having anew()
constraint and callingnew T()
is much more readable. Here's relevant link on the subject by Jon Skeet.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:
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):
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 anew 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:
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: