比詞典更快的替代品 <Type, X> ？

Question

我正在創建一個我正在進行性能測試的庫。 在其中我生成一個Dictionary<Type, X>一次。 這些項目目前以隨機順序插入。 字典在應用程序生命周期內保持不變。

然后它經常用於查找項目。 查找是庫中較大的瓶頸之一。

是的，我是微觀優化，但要學習。 我想知道是否有更好的方法來獲得查找性能？

更新

我用dotTrace來衡量性能。 報告+ dotTrace在我的家用電腦中，所以我這里沒有報告（否則可能會將其上傳到其他地方）。

我使用了這里的測試： https ： //github.com/danielpalme/IocPerformance

字典定義可在此處找到： https ： //github.com/jgauffin/Griffin.Container/blob/master/Source/Griffin.Container/ContainerBase.cs

（我上個星期五創建了容器，不要期望太多）

UPDATE2

如果我正確地解釋了數字， Dictionary.TryGetValue需要101ms的Resolve （總共251ms），這是40.2％。

Answer 1

如果類型是編譯時定義的，您可以嘗試像這樣實現它：

static class ValueFor<T>
{
  // you get another field per type T
  public static X X { get; private set; }

  internal static SetUpValue(X value) { X = value; }
}

只需使用此訪問權限。

var myIntX = ValueFor<int>.X;

Answer 2

Daniel Palme的IoC容器的性能基准（但也包括其他人）也有點誤導，因為基准測試解決了容器中非常淺的對象圖（雖然它確實清楚地表明容器之間的性能差異很大）。 這是不現實的，因為大多數應用程序（正確使用DI）將具有包含對象劑量的對象圖。 執行此操作時，只需要解析根對象，並且在正確寫入容器時，這意味着在大多數情況下（或者在以下情況下）您將只能單次調用Dictionary<T,V>.TryGetValue per（web）請求大多數只是）。 因此， Dictionary<T, V>的性能並不是真正的問題。

我認為， TKey為System.Type的Dictionary<T,V>的性能成本的最大部分與為給定Type生成哈希碼的性能成本有關。 每次調用TryGetValue ，都必須調用Type.GetHashCode() 。 GetHashCode是虛擬的（不能內聯），該方法調用3個其他虛擬方法。 最后，對RuntimeHelpers.GetHashCode(key)進行靜態（外部）調用。

換句話說，您將能夠優化性能以編寫使用Type作為鍵的特定（非泛型）字典類，而不是調用Type.GetHashCode()您應該調用RuntimeHelpers.GetHashCode(key) 。

更新（2013-04-05）：

幾個月前，我試圖提高我維護的DI容器的性能，並且我在優化字典部分。 我編寫了自己的字典，直接調用RuntimeHelpers.GetHashCode(key) （並跳過了虛擬調用），但最終性能提升到如此之小（在Palme的基准測試中大約1％），我決定恢復這些代碼更改。 所以我目前的理解是，使用Dictionary<Type, X>的實際性能成本實際上是在RuntimeHelpers.GetHashCode(key)中發生的所有事情。