Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>As always, the only correct way to answer a question about performance is to actually measure the code.</p> <p>Here's a sample <a href="http://linqpad.net" rel="noreferrer">LINQPad</a> program that tests:</p> <ul> <li>Activator.CreateInstance</li> <li>new T()</li> <li>calling a delegate that calls new T()</li> </ul> <p>As always, take the performance program with a grain of salt, there might be bugs here that skews the results.</p> <p>The output (timing values are in milliseconds):</p> <pre>Test1 - Activator.CreateInstance&lt;T&gt;() 12342 Test2 - new T() 1119 Test3 - Delegate 1530 Baseline 578 </pre> <p>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.</p> <p>Cautionary conclusion would be that <code>Activator.CreateInstance&lt;T&gt;</code> is taking roughly 11 times as much time to do the same job as a <code>new T()</code> 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.</p> <p><strong>Edit:</strong> 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.</p> <p>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.</p> <p>In any case, and here is my real answer:</p> <blockquote> <p><strong>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.</strong></p> </blockquote> <p>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 <em>is</em> the bottleneck.</p> <p>The program:</p> <pre><code>void Main() { const int IterationCount = 100000000; // warmup Test1(); Test2(); Test3(); Test4(); // profile Activator.CreateInstance&lt;T&gt;() Stopwatch sw = Stopwatch.StartNew(); for (int index = 0; index &lt; IterationCount; index++) Test1(); sw.Stop(); sw.ElapsedMilliseconds.Dump("Test1 - Activator.CreateInstance&lt;T&gt;()"); // profile new T() sw.Restart(); for (int index = 0; index &lt; IterationCount; index++) Test2(); sw.Stop(); sw.ElapsedMilliseconds.Dump("Test2 - new T()"); // profile Delegate sw.Restart(); for (int index = 0; index &lt; IterationCount; index++) Test3(); sw.Stop(); sw.ElapsedMilliseconds.Dump("Test3 - Delegate"); // profile Baseline sw.Restart(); for (int index = 0; index &lt; IterationCount; index++) Test4(); sw.Stop(); sw.ElapsedMilliseconds.Dump("Baseline"); } public void Test1() { var obj = Activator.CreateInstance&lt;TestClass&gt;(); GC.KeepAlive(obj); } public void Test2() { var obj = new TestClass(); GC.KeepAlive(obj); } static Func&lt;TestClass&gt; 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 { } </code></pre>
    singulars
    1. This table or related slice is empty.
    1. PODoes System.Activator.CreateInstance(T) have performance issues big enough to discourage us from using it casually?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USLasse Vågsæther Karlsen
    1. USLasse Vågsæther Karlsen
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PODoes System.Activator.CreateInstance(T) have performance issues big enough to discourage us from using it casually?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COInteresting 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 :(
      singulars
      1. PO
      1. USArunas
    2. COWell, 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.
      singulars
      1. PO
      1. USLasse Vågsæther Karlsen
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload