比Dictionary <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.TryGetValueResolve如果我正确地解释数字,则需要总共101ms (总共251ms),这是40.2%.

Answer 1

Daniel Palme 的 IoC 容器性能基准（以及其他人的性能基准）有点误导，因为该基准解析了容器中非常浅的对象图（尽管它确实清楚地表明容器之间的性能差异很大）。这是不现实的，因为大多数应用程序（正确使用 DI）都会有包含大量对象的对象图。执行此操作时，仅需要解析根对象，并且当正确编写容器时，这意味着Dictionary<T,V>.TryGetValue在大多数情况下（或最多只有少数情况），您只会对每个（Web）请求进行一次调用。因此，性能Dictionary<T, V>并不是真正的问题。

Dictionary<T,V>我相信whereTKey的性能成本的最大部分System.Type与为给定的生成哈希码的性能成本有关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)。