Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The performance benchmark for IoC containers from Daniel Palme (but those of others as well) is a bit misleading, since the benchmark resolves very shallow object graphs from the container (although it does show clearly that the performance differences between the containers are big). This is unrealistic, because most applications (that use DI properly) will have object graphs that contain dosens of objects. When doing this, only the root object needs to be resolved, and when the container is written properly, this means you will only have a single call to <code>Dictionary&lt;T,V&gt;.TryGetValue</code> per (web) request in most situations (or at most just a few). Because of this, the performance of <code>Dictionary&lt;T, V&gt;</code> is not really an issue.</p> <p>I believe that biggest part of the performance cost of <code>Dictionary&lt;T,V&gt;</code> where <code>TKey</code> is <code>System.Type</code>, has to do with the performance cost of generating a hash code for the given <code>Type</code>. Every time you call <code>TryGetValue</code>, <code>Type.GetHashCode()</code> has to be called. GetHashCode is virtual (can't be inlined) and that method calls 3 other virtual methods. In the end a static (external) call is made to <code>RuntimeHelpers.GetHashCode(key)</code>.</p> <p>In other words, you would be able to optimize performance to write a specific (non generic) dictionary class that uses <code>Type</code> as a key and instead of calling <code>Type.GetHashCode()</code> you should call <code>RuntimeHelpers.GetHashCode(key)</code>.</p> <p><strong>UPDATE (2013-04-05):</strong></p> <p>A few months back I tried to improve the performance of the DI container I maintain and I played with optimizing the dictionary part. I wrote my own dictionary that directly called <code>RuntimeHelpers.GetHashCode(key)</code> (and skipped the virtual calls) but in the end the performance gains where so small (around 1% in Palme's benchmarks) that I decided to revert these code changes. So my current understanding is that the real performance cost with <code>Dictionary&lt;Type, X&gt;</code> is actually everything that happens inside <code>RuntimeHelpers.GetHashCode(key)</code>.</p>
 

Querying!

 
Guidance

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